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DOCUMENT: BLM 80025B 


SOFTWARE REQUIREMENTS 
SPECIFICATION 
(SRS) 


DOCUMENT : 


PURPOSE: 


CONTENTS : 


BLM 80025B 


SOFTWARE REQUIREMENTS SPECIFICATION (SRS) 


The Software Requirements Specification (SRS) specifies 
the engineering and qualification requirements for a 
Computer Software Configuration Item (CSCI). 


The SRS is used as the basis for developing and testing 
a CSCI. Upon Government approval, it becomes part of 
the Allocated Baseline. 


This Data Item Description (DID) contains the format 
and content 
preparation instructions for completion of the Software 


Requirements Specification as required by 77-SDS-000102. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
taddored gout ." 


Document Structure: 


iv Scope 
Pati naldentitication 
1.2 System overview 
1.3 Document overview 
DA Applicable documents 
2.1 Government documents 
2.2 Non-Government documents 


3) Requirements. 

3.1 CSCI-external interface requirements 
CRN Ee. (Name/identifier of interfacing 
item) 

3.2 CSCI capability requirements 
Bex (Capability name and project-unique 

identifier) 

3.3 CSCI internal interfaces 

3.4 CSCI internal data element requirements 

3.5 Adaptation requirements | 
Bie wd Installation-dependent data 
Bn5.2 Operational parameters 

3.6 Sizing and timing requirements 

3.7 Safety requirements 

3.8 Security and privacy requirements 

3.9 Design constraints 

3.10 Software quality factors 

3.11 Human performance/human engineering 

requirements 

3.12 Requirements traceability 

As Qualification requirements 


4.1 Qualification methods 


BS, Lox 
shall 


4.2 Special qualification requirements 


De. Preparation for delivery 
63 Notes 
4 Appendizes 


Scope.. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCI to which this 
document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Applicable documents. This section shall be divided 
into the following paragraphs. 


Government documents. This paragraph shall contain a 
list of all Government publications referenced within 
this document including the Identification Number, 
Document Title, date of publication, and author (if 
known) . 


Non-Government documents. This paragraph shall contain 
a list of all Non-Government publications referenced 
within this document including the Identification 
Number, Document Title, date of publication, and author 
(i£ known). 


CSCI-external interface requirements. This paragraph 
shall be divided into subparagraphs to identify each 


required CSCI-external interface and specify the CSCI 
requirements associated with each interface. A diagram 
may be used to provide an overview of the interfaces. 


(Name/identifier of interfacing item). This paragraph 


state the name and project-unique identifier of an item 
with which the CSCI is required to interface (for 
example, a CSCI, system, HWCI, database, network or 
communications element, element of the software 
engineering or test environment, user, or operator), 


shall state the purpose of the interface, and ‘shall 

% itemize the interface requirements imposed on the CSCI 
to achieve the interface. This paragraph may reference 
an Interface Requirements Specification or other 
document that specifies these requirements. The 
requirements shall include, as applicable: 


a. Requirements pertaining to data elements the CSCI 
must send 
(output) or receive (accept as input), including, 
as applicable: 


identifier; 

description; 

sources; 

recipients; 

units of measure; 

limit/range of values; 
accuracy; 
precision/resolution; 

timing characteristics; 
legality checks that must be passed; 
data type; 
representation/format; and 
sequence or other dependencies 


+ + + + + + FH HF HF HF HK 


hat 
must be sent (output) or received (accepted as 
input) and required assignment of data elements to 


be Identification of each message or other data 
3 assembly t 


each 
(oP Required priorities among interfaces, data 
elements, 
messages, or assemblies 
d Specification of each interface/communications 


DEOLocolervnar 
must be used, including as applicable: 


* fragmentation/reassembly of messages; 

* message formatting; 
legality checks, error control and recovery 
procedures; 

synchronization; 

EVOWLCONCLOL? 

data transfer rate; 

routing, addressing, and naming conventions; 
transmission services; 

status and other reporting features; 
security; and 

privacy features 


+ 


+ + + HO F 


a2 CSCI capability requirements. This paragraph shall be 


Se 
paragraph 


divided into subparagraphs to itemize the requirements 
associated with each capability of the CSCI. A 
"Capability" is defined as a group of related 
requirements. The word "capability" may be replaced 
Meee runct2on, " "subject," "object," or other term 
useful for presenting the requirements. If the 
system of which the CSCI is a part can exist in various 
system states and modes as documented in the system 
specification, this paragraph shall correlate each CSCI 
requirement or group of requirements to those states 
and modes. A table may be used to depict this 
correlation. 


(Capability name and project-unique identifier). This 


shall identify a CSCI capability by name and project- 
unique identifier and shall state its purpose. If the 
capability can be more clearly specified by dividing it 
into constituent capabilities, each constituent 
capability shall be assigned a project-unique 
identifier derived from the identifier of the parent 
capability and shall be specified in subparagraphs. 
The paragraph for each capability or subcapability 
shall itemize the requirements associated with the 
(sub) capability. The requirements shall include 
applicable parameters, such as response times, 
sequencing, accuracy, capacities (how much/how many), 
priorities, continuous operation requirements, and 
allowable deviations based on operating conditions, and 
shall express these parameters in measurable terms. 
The requirements shall also include required behavior 
under unexpected or "out of bounds" conditions and any 
provisions to be incorporated into the CSCI to provide 
continuity of operations in the event of emergencies. 
Each requirement shall be stated in such a way that an 
objective test can be defined for it. 


CSCI internal interfaces. This paragraph shall 
identify any requirements imposed on the interfaces 
between the capabilities identified above. If all 
internal interfaces are left to the design, this fact 
shall be so stated. Each internal interface on which 
requirements are imposed shall be identified by name 
and project-unique identifier and the interface 
requirements shall be itemized. Internal interface 
diagrams depicting data flow, control flow, and other 
relevant information may be used to aid in this 
description. | 


CSCI internal data element requirements. This 
paragraph shall specify any requirements imposed on the 


data elements internal to the CSCI. If all decisions 
about internal data elements are left to the design, 
this fact shall be so stated. If they have been 


Bie 3d 


covered elsewhere in this specification, they need not 
be repeated here. If requirements are imposed on data 
elements internal to the CSCI, they shall include, as 
applicable: 


ay A project-unique identifier for the data element 


De A brief description of the data element 
a Units of measure required for the data element, 


such as 
seconds, meters, dollars 


d Limit/range of values required for the data 


element (for 


constants, the actual value) 
e. Accuracy required for the data element 


fe Precision or resolution required for the data 


element in 


terms of significant digits 


Ga Required format, such as field definitions 


Adaptation requirements. This paragraph shall be 
Givided into the following subparagraphs to specify any 


adaptation requirements for the CSCI. 


Installation-dependent data. This paragraph shall 


describe any 


any 


Site-unique data required by each installation. 
Examples of such data are: site latitude and longitude, 
radar ranges and areas of coverage, and prescribed 
safety limits. In addition, this paragraph shall 
identify the CSCI capabilities in which these data are 
used. 


Operational parameters. This paragraph shall describe 


parameters required by the CSCI that may vary within a 
specified range according to operational needs. 
Examples of such data are: allowable trajectory 
deviations, navigation set model numbers, airplane 
performance characteristics, interaction/isolation of 
sorties, missile performance characteristics. This 
paragraph shall identify the CSCI capabilities in which 
these data are used. 


Sizing and timing requirements. This paragraph shall 
specify: 


a Sizing requirements on the CSCI, including, as 


applicable: 


1) Amount/type/location of internal and 


auxiliary memory 


allocated to the CSCI 


2) Any variations between normal operation and 
; contingency operations 
3) Any other constraints imposed by the planned 
memory 
available to the CSCI 
bs Timing requirements on the CSCI, including, as 
applicable: 
si) The amount of processing time allocated 
to the 
CSEL 
2) Required throughput time 
3) Required response time to queries and 
other 
requests 
4) Sequential/concurrency relationships of 
CSCIs 
5) Sequential/concurrency relationships of 
CSCe 
capabilities 
6) Priorities imposed by type of inputs and 
modes of 
operation 
7) Timing requirements for range of loads 
under 
varying operating conditions 
8) Required input/output transfer times 

Shes Safety requirements. (If applicable). This paragraph 
shall specify any safety requirements applicable to the 
CSCI, concerning potential hazards to personnel, 
property, or equipment. 

3.8 Security and privacy requirements. This paragraph 
shall specify any CSCI requirements concerned with 
security and privacy. These requirements shall 
include, as applicable: 

a. The type and degree of security or privacy of data 
that are 


permitted or required to be used in or processed 
by the CSCI, including whether the data are always 
sensitive, become sensitive upon the occurrence of 


10 


el 


specific events, or change their degree of 
sensitivity upon the occurrence of specific events 


be The type and degree of security or privacy of the 
algorithms 
that are permitted or required to be used in the 
CScr 
Gs. The security and privacy environment that can be 


assumed to 
exist when the CSCI will be in operation 


Design constraints. This paragraph shall specify any 
other requirements that constrain the CSCI design, such 
as the use of a particular processing configuration. 

If there are no constraints imposed on the CSCI design, 
this fact shall be so stated. 


Software quality factors. This paragraph shall be 
divided into subparagraphs as needed to specify any 
software quality factors identified in the contract or 
derived from a higher level specification and the 
method to be used to determine whether each quality 
factor has been met. These factors shall include: 


* reliability (the ability to perform with correct, 
consistent 
results), 


* maintainability (the ability to be easily 
corrected), 


* availability (the ability to be accessed when 
needed) , 


* flexibility (the ability to be easily adapted to 
changing 
requirements) , 


* portability (the ability to be easily modified fora 
new 
hardware environment), 


* reusability (the ability to be used in multiple 
applications), 


* testability (the ability to be easily and thoroughly 
tested), 
and 


* usability (the ability to be easily learned and 
used) 


Human performance/human engineering requirements. This 


yl 


paragraph shall specify any human factors engineering 
requirements imposed on the CSCI. These requirements 
shall include, as applicable, considerations for: 


a. Human information processing capabilities and 
limitations be Foreseeable human errors under both 
normal and -.extreme 

conditions 

ra Implications for the total system environment 

(include 


training, support, and operational environment) 


Requirements traceability. This paragraph shall 
contain: 


a. A mapping of the engineering requirements in this 
specification to the system requirements allocated 
LOSthtseecSCr 


b: A mapping of the system requirements allocated to 
this, CSCL 
to the engineering requirements in this 
specification 


Qualification requirements. This section shall be 
divided into the following paragraphs to specify the 
qualification requirements for the CSCI. 


Qualification methods. This paragraph shall define a 
set of qualification methods and specify the 
qualification method(s) to be used to ensure that each 
requirement in sections 3 and 5 has been met. 
Qualification methods may include: 


ae Demonstration: The operation of the CSCI (or some 
part of 
the CSCI) that relies on observable functional 
operation not requiring the use of instrumentation 
or special test equipment. 


ba Test. The operation of the CSCI (or a part of the 
CSCcy) 
using instrumentation or other special test 
equipment to collect data for later analysis. 
ae Analysis: The processing of accumulated data 


obtained from 
other qualification methods. Examples are 
reduction, interpretation, or extrapolation of 
test results. 


a: Inspection: The visual examination of CSCI code, 
document - 
ation, etc. 


Special qualification requirements. This paragraph 
shall be divided into subparagraphs as needed to 


specify any special requirements associated with 
qualification of the CSCI. This paragraph shall 
identify and describe, if applicable, special tools, 
techniques (e.g., test formulas, algorithms), 
procedures, facilities, and acceptance limits. For 
each special test the following information shall be 


specified: 
a. A project-nique identifier for the test 
Dp. The paragraph number(s) of the requirements to 
which the 
test applies 
er A description of the test, such as peak-load 


stress test for 
24 hour duration 
el The level of the test (software unit, CSCI, 
segment, or 
system level) 


Preparation for delivery. This section shall specify 
any requirements on the type and characteristics of the 


delivery media for the CSCI (e.g., 8 track magnetic 
tape 1600 BPI, 150 megabyte disk); the labeling, 
packaging, handling, and classification marking 
requirements for the media; and any unique delivery 
requirements. 


Notes. This section shall contain any general 
information that 
aids in understanding this specification (e.g., 
background information, glossary, formula derivations, 
rationale). This section shall include an alphabetical 
listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any 
terms and definitions needed to understand this 
document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 


“DOCUMENT: BLM 80026B 


INTERFACE REQUIREMENTS 
SPECIFICATION 
(IRS) 


DOCUMENT : 


PURPOSE: 


CONTENT : 


BLM 80026B 


INTERFACE REQUIREMENTS SPECIFICATION (IRS) 


The Interface Requirements Specification (IRS) 
specifies the requirements for one or more interfaces 
between one or more Computer Software Configuration 
Items (CSCIs) and other configuration items or critical 
items. 


The IRS can be used: 


a) To document the interface characteristics of 
existing CSCIs (saying, in essence, "To send data to, 
or receive data from, these CSCIs, you must follow 
these rules") or, 


b) To specify requirements for the interface 
characteristics of new or being-modified CSCIs (saying, 
in essence, "The CSCIS are required to send/receive 
data in accordance with the following rules"). 


The IRS supplements the Software Requirements 
Specifications as the basis for developing and testing 
CSCIs. Upon Government approval, the IRS becomes the 
joint configuration control device for the interface(s) 
and becomes part of the Allocated Baseline. 


This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
Requirements Document and Consolidated Software 
Development Record). Only one of these three DIDs 
should be applied to a given set of data. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailoredmout.." 


DOCUMENT STRUCTURE: 


i Scope . 

ieee LOCHLIT ication. 

1.2 System overview. 

1.3 Document overview. 
PIS Applicable documents. 

2.1 Government documents. 

2.2 Non-Government documents. 
ae Interface requirements. 


NO U1 


3.1 Interface identification and diagrams. 
3.x (Interface name and project-unique 
identifier). 


Besorl Data element requirements. 

S2xO2 Messages or other data assemblies. 

3.3 Interface priorities. 

Bi .4 Interface/communication protocols. 
a3X04 By (Protocol name). 


Qualification requirements. 

4.1 Qualification methods. 

4.2 Special qualification requirements. 
Preparation for delivery. 

Notes. 

Appendixes. 


Scope. This section shall divided into the following 
paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system(s), CSCI(s), and 
interfaces to which this document applies, including, 
as applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release 
number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system(s), software, and interfaces 
to which this document applies. It shall describe the 
general nature of the system and software; summarize 
the history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Applicable documents. This section shall be divided 
into the following paragraphs. 


Government documents. This paragraph shall begin with 
one of the following, as applicable: 


(1) "The following documents of the exact issue shown 
form a part of this specification to the extent 
specified herein. In the event of conflict between the 
documents referenced herein and the contents of this 
specification, the contents of this specification shall 
be considered a superseding requirement." 


(2) "The following documents of the exact issue shown 
form a part of this specification to the extent 
specified herein. In the event of conflict between the 
documents referenced herein and the contents of this 
specification, the contents of this specification shall 
be considered a superseding requirement, except for 
specification (enter number of next higher-tiered 
specification) listed below." 


Non-Government documents. This paragraph shall begin 
with the following paragraph: "The following documents 
of the exact issue shown form a part of this 
specification to the extent specified herein. In the 
event of conflict between the documents referenced 
herein and the contents of this specification, the 
contents of this specification shall be considered a 
superseding requirement. " The source for all 
documents not available through normal Government 


stocking activities shall be listed. The following 
paragraph shall be placed at the conclusion of the list 
when applicable: "Technical society and technical 
association specifications and standards are generally 
available for reference from libraries. They are also 
distributed among technical groups and using Federal 
Agencies. " Non-Government documents shall be listed 
by document number and title in the same order as under 
Ze, 


Interface requirements. This section be divided into 
the following paragraphs to specify the requirements 
for those interfaces to which this IRS applies. 


Interface identification and diagrams. This paragraph 
shall identify the interfaces to which this 


specification applies. The interfacing items may 
include systems, other configuration items, and support 
software and hardware, such as utilities and test 
software, databases, and items in the communications 
environment. The identification of each item shall 
include its name, number, version, and documentation 
references. The identification shall state which items 
already exist (and therefore impose interface 
requirements on interfacing items) and which are being 
developed or modified (thus having interface 
requirements imposed on them). One or more interface 
diagrams, aS appropriate, shall be provided to depict 
the interfaces. Each interface shall be identified by 
name and project-unique identifier, and shall specify, 
as applicable, the type of interface required 
(sequential or concurrent operation, real-time data 
transfer, store-and-retrieve data transfer, operator 
controlled, etc.). 


(Interface name and project-unique identifier). This 
paragraph (beginning with 3.2) shall identify an 
interface by name and project-unique identifier, shall 
state its purpose, and shall be divided into the 
following subparagraphs. Requirements for an 
interface may cover: 


1) characteristics of the data sent/output by an 
existing item; 


2) characteristics that data must have to be 
received/input by an existing item; 
3) requirements a new or being-modified item must 


meet with respect to data sent/output to 
interfacing items; 


4) requirements a new or being-modified item must 
meet with respect to data it must be able to 


cies, aaa 


receive/input from interfacing items; or any 
meaningful combination or variation of these 
options. When describing interface 
characteristics of existing items, read 
"established" for "required." 


Data element requirements. This paragraph shall 


specify any 


the 


must 


requirements pertaining to the data elements to be 
transmitted between the interfacing items, including, 
as applicable: 


a. A project-unique identifier for the data element 
lols A brief description of the data element 
Cc. The CSCI, HWCI, or other item that is the source 


of the data 
element, and an indication of which of these, if 
any, is imposing the requirement 

ro The CSCI(s), HWCI(s), or other item(s) that are 


recipients of the data element, and an indication 
of which of these, if any, is imposing the requirement 
e. The units of measure in which the data element 
be sent 
or received, such as seconds, meters, kilohertz, 
dollars, etc. 
ia The limit/range of values that must be sent or 
received for 
the data element (for constants, provide the 
actual value; 
when applicable, state allowable codes, allowable 
messages, allowable message types.) 


q. The accuracy that must be possessed by the data 
element 

(permissible deviation from an ideal value) 
igi The precision or resolution with which the data 


element must 


pass 


data 


be sent or received, in terms of number of 
Significant digits 
oe The timing characteristics with which the data 
element must 
be sent or received (how often transmitted or 
received, transmitted for how long, etc.) 


the Legality checks the data element must be able to 
k. The data type (such as integer, ASCII, real, 
enumerated, 
etc.) in which the data element must be sent or 
received 
Le The data representation/format in which the data 
elements 
must be sent or received 
m. The sequence and other dependencies with which the 


S 


ee ae 


elements must be sent or received 


Messages or other data assemblies. This paragraph 


shall specify 


3.x.4 
shall be 


3.x.4.y 


any requirements concerning messages or other 
assemblies of data elements to be transmitted between 
the interfacing items. It shall identify each such 
message or assembly by name and project**“unique 
identifier and shall describe the assignment of data 
elements to each message or assembly. 


Interface priorities. This paragraph shall specify any 
requirements concerning the relative priority of the 
interface or the data elements, messages, or assemblies 
transmitted between the interfacing items. 


Interface/communication protocols. This paragraph 


divided into the following subparagraphs to specify any 
requirements concerning commercial, military, or 
proprietary communications protocols to be used for the 
interface. 


(Protocol name). This paragraph shall identify a 


protocol by 


name and shall specify or reference the requirements 
for the protocol, including, as applicable: 


a. Fragmentation and reassembly of messages 

eh Message formatting 

Gt Legality checks, error control, and recovery 
procedures, 


including fault tolerance, handling of "out-of- 
bounds" conditions, and features to ensure 
continuity of operations in the event of 


emergencies 
dz Synchronization, including connection 
establishment, 


and 


Maintenance, termination, and timing 
e. Flow control, including sequence numbering, window 
size, and 

buffer allocation 
i Data transfer rate, whether periodic or aperiodic, 


minimum interval between transfers 
Gq. Routing, addressing, and naming conventions 
hi). Transmission services, including priority and 
Graders status, identification, notification, and any 
other 
reporting features 
Ss Security and privacy, including encryption, user 
authentication, compartmentalization, and auditing 


Qualification requirements. This section shall be 


AP 


divided into the following paragraphs to specify the 
qualification requirements associated with the 
interfaces. 


Qualification methods. This paragraph shall define a 
set of qualification methods and shall specify the 


qualification method(s) to be used to ensure that each 
requirement in section 3 has been met. A table may be 
used to present this information, or each requirement 
in Section 3 may be annotated with the method(s) to be 
used. Qualification methods may include: 


a. Demonstration: The operation of a CSCI, or 
combination of 
interfacing items, that relies on observable 
functional operation not requiring the use of 
instrumentation or special test equipment. 


DE Test. The operation of a CSCI, or combination of 
inter- 
facing items, using instrumentation or special 
test equipment to collect data for later analysis. 


ae Analysis: The processing or examining data 
obtained from 
other qualification methods. Examples are 
reduction, interpretation, or extrapolation of 
test results. 


ae Inspection: The visual examination of CSCI code, 


document - 
aLiLOn, seUCC:, 


Special qualification requirements. This paragraph 


shall be divided into subparagraphs as needed to 
specify any special qualification requirements 
associated with the interfaces to which this 
specification applies. This paragraph shall identify 
and describe, if applicable, special tools, techniques 
(e.g., test formulas, algorithms), procedures, 
facilities, and acceptance limits. For each special 
test the following information shall be specified: 


Bis A project-unique identifier for the test 
Db; The paragraph number(s) of the requirements to 
which the 


test applies 


ek: A description of the test, such as peak-load 


stress test for 
24 hour duration 


ai The level of the test (software unit, CSCI, 


segment, or 


system level) 


Preparation for delivery. This section shall state 
"NONE." 


Notes. This section shall contain any general 
information that 

aids in understanding this document (e.g., background 
information, glossary, rationale, etc.). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations and their meanings as used in this 
document and a list of any terms and definitions needed 
to understand this document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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INTERFACE DESIGN DOCUMENT (IDD) 


PURPOSE: The Interface Design Document (IDD) describes the 
detailed design of one or more interfaces between one 
or more Computer Software Configuration Items (CSCIs) 
and other configuration items or critical items. 


The IDD may be used: a) To document the interface 
characteristics of existing CSCIs (saying: "To send 
data to, or receive data from, these CSCIs, you must 
follow these rules") or b) To describe the interface 
characteristics selected for new or being-modified 
CSCIs in response to interface requirements (saying: 
"The CSCIs will send/receive data in accordance with 
the following rules"). 


CONTENT: This Data Item Description (DID) contains the format 
and content preparation instructions. 


An alternative to this DID may be used for small 
development projects by incorporating the data from 
this DID into the Consolidated Software Design 


Document. 
The IDD and its companion Interface Requirements 
A Specification (IRS) serve to communicate and control 


interface design decisions. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." For data delivered in an alternative 
form, this representation need occur only in the table 
of contents or equivalent. 


DOCUMENT STRUCTURE: 


alee Scope 
1 ieeeLOentiriacation 
1.2 System overview 
1.3 Document overview 
2 Referenced documents 
35 Interface design 
3.1 Interface identification and diagrams 
3.x (Interface name and project-unique 


identifier) 
SGA Sell Data elements 
Bikes Messages or other data assemblies 
cee age Interface priorities 
35X44 


2 Interface/communication protocols 
‘N BK ds ¥ (Protocol name) 
4. Notes 
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Scope. This section shall divided into the following 
paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system(s), CSCIs(s), and 
interfaces to which this document applies, including, 
as applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release 
number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system(s), software, and interfaces 
to which this document applies. It shall describe the 
general nature of the system and software; summarize 
the history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Referenced documents. This section shall list by 
document and title all documents referenced in this 
document. This section shall also identify the source 
for all documents not available through normal 
Government stocking activities. 


Interface design. This section shall be divided into 
the following paragraphs to describe the interface 
design (that is, the specific interface characteristics 
selected to respond to the interface requirements) for 
those interfaces to which this IDD applies. If part or 
all of this information is documented elsewhere, it may 
be referenced. 


Interface identification and diagrams. This paragraph 
shall describe for each CSCI to which this IDD applies, 


its relationship to the other HWCIs, CSCIs, or critical 
items with which it interfaces. This description may 
be provided by one or more interface diagrams, as 
appropriate, and shall characterize each interface 
(sequential or concurrent operation, real-time data 
transfer, store-and-retrieve data transfer, operator 
controlled, etc.). 


(Interface name and project-unique identifier). This 
paragraph (beginning with 3.2) shall identify an 
interface by name and project-unique identifier and 
shall state its purpose. This paragraph shall be 
divided into the following subparagraphs. 


Data elements. This paragraph shall provide, possibly 
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in a data 


element definition table, the following information, as 
applicable, for each data element transmitted between 
the interfacing items: 


a. A project-unique identifier for the data element 


ba A brief description of the data element 
wed The CSCI, HWCI, or other item that is the source 
of the data 
element 
a. The CSCI(s), HWCI(s), or other item(s) that are 
the 
recipients of the data element 
e. The units of measure of the data element, such as 
seconds, 
meters, dollars 
ce The limit/range of values of the data element (for 
constants, provide the actual value) 
g. The accuracy of the data element 
hz The precision or resolution of the data element in 
terms o 


Significant digits 
ales The timing characteristics of the data element, 


for example, 


pass 


real, 


ae 2 


how often sent or received, how long transmitted 
Legality checks the data element must be able to 


The data type, such as integer, ASCII, fixed, 
enumerated 
ie The data representation/format 
m. The sequence and other dependencies of the data 
element 


Messages or other data assemblies. This paragraph 


shall identify 


ax. 3 
relative 


by name and project-unique identifier each message or 
other assembly of data elements to be transmitted 
between the interfacing items, and shall describe the 
assignment of data elements to each message or 
assembly. A cross-reference from each message or 
assembly to the data elements it contains and a cross- 
reference from each data element to the messages or 
assemblies containing it shall be provided, possibly in 
an appendix. 


Interface priorities. This paragraph shall specify the 
priority of the interface and of each data element, 


message, or assembly transmitted between the 
interfacing items. 


Interface/communication protocols. This paragraph 
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divided into the following subparagraphs to describe 
the commercial, military, or proprietary communications 
protocols associated with the interface. 


(Protocol name). This paragraph shall identify a 


name and shall describe the technical details of the 
protocol, including, as applicable: 


a. Fragmentation and reassembly of messages 

Be Message formatting 

Cs Legality checks, error control and recovery 
procedures, 


including fault tolerance, handling of "out-of- 
bounds" conditions, and features to ensure 
continuity of operations in the event of 


emergencies 
qi: Synchronization, including connection 
establishment, 
Maintenance, termination, and timing 
e. Flow control, including sequence numbering, window 
size, and 
buffer allocation 
ce Data transfer rate, whether it is periodic or 
aperiodic, and 
minimum interval between transfers 
eh Routing, addressing, and naming conventions 
ne Transmission services, including priority and 
grade 12, Status, identification, notification, and any 
other 


reporting features 
le. Security and privacy, including encryption, user 
authentication, compartmentalization, and auditing 


Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary, formula 
derivations). This section shall include an 
alphabetical listing of all acronyms, abbreviations, 
and their meanings as used in this document and a list 
of any terms and definitions needed to understand this 
document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENTS : 
the CSCI 


BLM 80012B 
SOFTWARE DESIGN DOCUMENT (SDD) 


The Software Design Document (SDD) describes the design 
of a Computer Software Configuration Item (CSCI). 


It describes CSCI-wide design decisions and conventions, 


architecture, the allocation of CSCI requirements to 
software units, and the design details needed to code the 
software corresponding to each unit in the selected 
programming language. 


The SDD is used by the Bureau of Land Management to 
obtain visibility into the design, to verify that all 
CSCI requirements have been allocated for implementation, 
and to assess the supportability of the software. 


Document Structure: 
NA Scope. 
(lee lOocie La cat Lon. 
1.2 System overview. 
1.3 Document overview. 
Referenced documents. 
CSCI-wide behavioral design. 
CSCI design conventions 
CSCI architectural design 
5.1 Role in the system architecture 
Bi 271CSCLi architecture 
6. CSCI detailed design 
6.x (Software unit name and project-unique 
identifier) 
Requirements traceability 
Notes 
Appendixes 
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ibe Scope. This section shall be divided into the following 


paragraphs. 
ad. Identification. This paragraph shall contain a full 
identification 
of the system and the CSCI to which this document 
applies, includ-ing, as applicable, identification 


number(s), title(s), abbreviation(s), version number(s), 
and release number(s). 


2 System overview. This paragraph shall briefly state the 
purpose of 

the system and the software to which this document 
applies. It shall describe the general nature of the 
system and software; summarize the history of system 
development, operation, and maintenance; identify the 
project sponsor, user, developer, and support agencies; 
identify current and planned operating sites; and list 
other relevant documents. 


Hee Document overview. This paragraph shall summarize the 
purpose and 
contents of this document. 


Ze Referenced documents. This Tsection Vishall “istoiby 
document number 
and title all documents referenced in this document. 
This section shall also identify the source for all 
documents not available through normal Government 
Stocking activities. 


Se CSCI-wide behavioral design. This section shall be 
divided into 


paragraphs as needed to describe CSCI design decisions 
that transcend the internal structure of the CSCI. 
Examples may include decisions about: how the CSCI will 
appear to the user, how the CSCI will behave, appearance 
of displays/reports, meanings of console keys, and other 
choices for meeting the CSCI requirements. If all such 
decisions are explicit in the CSCI requirements or are 
deferred to the design of the CSCI’s software units, this 
section may so state. Otherwise, this section shall 
include, as applicable: 


a. Decisions on allowed/expected inputs from users and 
other 
sources, including name(s), source, media, volume, 
frequency, sequence, priority, timing, security, 
privacy, format, units of measure, range of values, 
abbreviations, codes, examples. 


De Decisions on planned behavior in response to each 
rete) bie y 
including actions, sequence, conditional behavior, 
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timing, selected equations /algorithms/rules, 
disposition, and handling of illegal or "out-of- 
bounds" inputs. 


or Decisions on CSCI-produced outputs (displays, 
reports, etc.), 
including name(s), format/layout, media, volume, 


frequency, priority, timing, recipients, forms, 
security, privacy, units of measure, range of 
values, abbreviations, codes, disposition, 
examples. 


ax Decisions on CSCI-contained databases/data banks, 
including 
(1) contents: size, records/entries, media, 
security, 
privacy, retention schedule; (2) data elements: 
name(s), definitions, units, formats, range, 
abbreviations, security, privacy, and codes for the 
data elements; (3) relationship tbo CSCI 
Sa aDielaite es /*Luncttons ; (43) data 
retention/reporting. Reference may be made to 
Database Design Documents for this information. 


e. Decisions on the type of flexibility to be built 
into the CSCI 
for adapting to changing requirements. 


1D Decisions on the levels and types of availability, 
security, 
privacy, and continuity of operations to be offered 
byacthesCSCL. 


CSCI design conventions. This section shall explain any 


rules, schemes, and conventions used in designing the CSCI 


and expressing that design. Design standards may 
be referenced. This information shall include, as 
applicable: 


a. Mnemonic identifiers and their use in labeling 
software units, 
data structures, data elements, storage areas, 
etc., including provisions for unique naming at 
different sites. 
ley Conventions for design diagrams, listings, 
abbreviations, 
comments, and symbols appearing in diagrams and 
listings. 


cz Standard data elements and related features. 
CSCI architectural design. This section shall be divided 


into the 
following paragraphs to describe the CSCI architectural 
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design. The information may be presented graphically, 
for example in diagrams, tables, or flow charts. lbh 
diagrams or other graphical representations contain 
information required by more than one paragraph, they may 
be presented once and referenced from subsequent 
paragraphs rather than repeated. 


Role in the system architecture. This paragraph shall 
describe the role of the CSCI within the system 
architecture, including the purpose of each external 
interface of the CSCI. A system architecture diagram may 
be used to show the relationships between this CSCI and 
other configuration items in the system. 


CSCI architecture. This paragraph shall describe the 
internal 

architecture of the CSCI. If a system operates in states 

or modes, it shall identify each state or mode and the 

changes in (a) through (d) below for each. This 

paragraph shall: 


a. Identify and state the purpose of each software unit 
comprising the architecture. 


DA Describe the structure (such as network, 
hierarchical) of the 

CSCI in accordance with the methodology described 

in the software development plan, including, as 
applicable: 


1) The flow of execution control among software 


any dynamically controlled sequencing during 
the CSCI’s operations, include: 


a) The method for sequence control 


b) Mhes logic and input conditions of that 
method, such 
as timing variations, timing 
relationships between interrupt or 
sensing operations, priority assignments. 


Cs) The flow of control for exceptions and 
other error 
detection and recovery features. 


d) The flow of control between concurrently 
executing 
processes. 
2) The flow of data among software units. 


ote Identify any non-developmental software to be 
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(oe Identify the allocation of memory and processing 
to the 
software units. The allocation may be illustrated 
by a memory/processing time table. 


CSCI detailed design. This section shall be divided into 
following paragraphs EO provide a design 
description of each software unit of the CSCI. The 
information may be presented graphically, for example in 
diagrams, tables, or flow charts; in a program design 
language; or by reference to other design represent- 
ations including headers of the code. If diagrams or 
other representations contain information required by 
more than one paragraph, the diagram or representation 
may be presented once and referenced from subsequent 
paragraphs rather than repeated. 


(Software unit name and project-unique identifier). This 
paragraph 

shall identify a software unit by name and project-unique 
identifier. Alternatively, it may identify a group of 
software units, with each software unit identified ina 
subparagraph numbered 6.x.y. The design description of 
each software unit shall include the following, as 
applicable: 


a. The purpose of the software unit. 
Db: The requirements allocated to the software unit from 
the applicable requirements specification(s). 
cr The derived design requirements for the software 
Litt FOr 
example, the algorithms to be incorporated into the 
software unit. 
a: Any constraints, limitations, or unusual features in 
the design of The software unit. 
e. The programming language and rationale for its use 
Piast ie software unit or any part of it is to be 


coded in a programming language other 
than the specified CSCI language. 


a If part or all of the software unit is to be 


implemented by 


existing reusable software, the identifier of the 
reusable software, the software library in which it 
resides, and the design document in which its 
design can be found. 
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Gs The program library in which the software unit is to 
be placed. 

he The inputs, outputs, and other data elements of the 
software : 

unit, including, as applicable for each: 

1} Project-unique identifier. 

2) Brief description including purpose. 

3) Units of measure, such as knots, seconds, 

meters, 

dollars. 

4) Limit/range of values (for constants, the 

actual value) 5) Accuracy. 

6) Precision/resolution in terms of significant 

digits 7) Priority: 

8) Frequency at which the data element is input, 
calculated, 

refreshed, or output such as 10 Khz, 50 Msec, 
etc. 

9) Legality checks to be performed on the data 

element etc. 10) D a c a 

representation/format/structure. 

11) Sources, including other software units where 

the data 

element is set or calculated. 
12) Destinations, including other software units 
where the 

data element is used. 

13) Maximum size and storage needs. 

14) Access method, such as random or sequential. 
an The logic flow to be used by the software unit, 
including: 

ic) Conditions under which software unit execution 

is 

initiated. 

2) Conditions under which control is passed to 

other 


software units. 


3) Response and response time to each input, 
including data 
conversion, renaming, and data transfer 
operations. 
4) Dynamically controlled sequencing during the 
software 


unit’s operations, including: 


a) The method for sequence control. 
b) The logic and input conditions of that 
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method, such 


as timing variations, PELOrIEy 
assignments. 
Gy) Data transfer in and out of memory. 
d) The sensing of discrete input signals, 
and timing 
relationships between interrupt 


operations within the software unit. 


Requirements traceability. This section shall provide 
traceability 
from the CSCI requirements to the software units. The 


tracea-bility may be shown in a table. 


Notes. This section shall contain any general 
information that 
aids in understanding this document (e.g., background 


information, glossary, formula derivations, rationale). 
This section shall include an alphabetical listing of all 
acronyms, abbreviations, and their meanings as used in 
this document and a list of any terms and definitions 
needed to understand this document. 


Appendixes. Appendixes may be used to provide 
information 

published separately for convenience in document 

Maintenance Cena, charts, classified data). As 


applicable, each appendix shall be referenced in the main 
body of the document where the data would normally have 
been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENTS : 


BLM 80032B 


DATABASE DESIGN DOCUMENT (DBDD) 


A Database Design Document (DBDD) describes the logical 
and physical design of a database and gives information 
necessary for the construction of the database and for 

its use by application programmers. 


A DBDD is prepared when multiple Computer Software 
Configuration Items (CSCIs) will use the same database 
or when a database used by a single CSCI is 
sufficiently complex that its structure cannot be 
readily described in the CSCI’s Software Design 
Document (SDD). The design of a Database Management 
System (DBMS) is described in an SDD or equivalent 
document, rather than in a DBDD. 


This document contains a description of the database 
environment and system information regarding the DBMS. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
baaloned Out.” 


Document Structure: 


ILS, Scope 
1.1 Identification 
1.2 Database overview 
1.3 Document overview 


aie Referenced documents 
Be Database overview 
3.1 Database environment 
Pelee Systems using the database 
Sites Relationship to other databases 
pg ae Storage requirements 
Bl 4 Physical mapping of database files 
Srl 5 Communications environment 
3.2 Labeling conventions 
3.3 Organization of the database 
he Cpe k Conceptual model 
Sse Physical allocation 


3.4 Special instructions 
3.5 Support software available for handling the 


database 
3.6 Security, privacy, and criticality 
as Database administrative information 


4.1 Responsibility 
4.2 System information 
Ale ars. Database Management System (DBMS) 
configuration 
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420292 
Ag 2199 
45244 

4.3 Schem 
45-301 
A302 
4.3.3 
subschemas 
423.4 
Aes y5 
2.356 
4.3.7 
4.3.8 

4.4 Area/file 
4.4.1 
4.4.2 
4.4.3 
4.4.4 
4.4.5 

Use of t 


Dre 


SDK 


Hardware configuration 
Database software utilities 
Security and privacy 


a information 


Rationale 
Database content 
Description of schema and 


Logical structure 

Physical structure 

Sizing 

Recovery 

Requirements cross-reference 
information 

Rationale 

Content of areas/files 
Description of areas/files 
Storage control parameters 
Recovery 


he database by (identification of a CSCI 


Descriptions of the 
database 
(Identification of a subschema or 


local view) 


5. ex al Records and their data 


elements 

She a 5 are, Sets 

Be 23 Areas/files 

Se 4 Access methods 


eae Security and privacy 


5.2 Database software utilities 
Ses eEreor handling 
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Messages 
Notes 
Appendixes 


nolietwpl 2 Too 
sre03IT0e8 


y IaVIAG Py; & 


TL 


a 
Ww 
me be OF. Oo Se os a Bp 


etewbit5H 
SPSS IBC 
voityoSe 
noljaemrotn: 


2. 


ee uere 


> mF 


¢ 


sfanoltjas I. 
of mo) opadesed S.€. 
sition 20 eaLtqladasd 7 
2cmSs3edie 
lyte. Laecioad Be v 
3 ry fsolevdd ©.t.2 
pee te ae 
Ay Tv. &.6 
(pos B. . 
eae: Lia \as TA 
rp 
33 : by f 
“era a 
; sg 1023 é 
5 [ef ; fe 
+ BD witb ‘Ti 
TJ. r . 
IE. 
} i> tik ce 
0) i 
h 
f 6tutl 
J isa rad be Ls 
S Fase 
- 
: 


ssh. DAeGoaR 


Si 
—- 


om 


oe 


a4) 


a pa 


Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the database to which this document 
applies, including, as applicable, identification 
number(s), title(s), abbreviation(s), version 
number(s), and release number(s). 


Database overview. This paragraph shall briefly state 
the purpose of the database to which this document 
applies. It shall describe the general nature of the 
database; summarize the history of its development, 
use, and maintenance; identify the project sponsor, 
user, developer, and support agencies; identify current 
and planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this plan. This section shall also identify the source 
for all documents not available through normal 
Government stocking activities. 

Database overview. 


Database environment. 


Systems using the database. This paragraph shall 


identify the 


2 opal Sa 
indicate 


eels: 3 
estimated 


3.1.4 


systems that will use this database, including, as 
applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release 
number(s). 


Relationship to other databases. This paragraph shall 


whether the database will supersede other databases and 
if so, which one(s). 


Storage requirements. This paragraph shall contain the 


internal and peripheral storage requirements for the 
database. Multiple storage requirements for 
distributed processing shall be included, as 
applicable, as well as differences applying to special 
modes of operation following emergency, disaster, or 
accident. 


Physical mapping of database files. This paragraph 


shall provide 


add out oe sci Chat: nbtaede’ nite 
‘RiqeTQeseT t 


s3con [lade dqsvpevea elAD . sank a bea he de 
:As rlotdw eo saedesa5 ent 2o soltenttisaee _ 
$i5 r ,sulenilogs as ,eititbufoa? jestiqgs s 
iebouljisiverdds . (a)esi923 . ler pclomisis * 

hadeut sepsley bas , (6) tec is 


eg eitT .weboievo. spedeied 

. needed ‘fj 30 saoa@xug: sty 

is tzogeh [isto 32° eetiogs ve 
“3 seivetrave ipagdasas 

;e0tensso lem She ome. 

; mo.eVved ,76eL 
‘ietede boenasiq bas 
1 Jnem eb 


rovo Joomroott 


siooiaod Anse eaceruG 


) eG beageszejed 
. Ysdmun Jagmsoep 
: ‘Ty .1tele els 
mooh ifs 163 
12 Sate VoOo 


bé 


t\yevo sredated 
ad Oo Le Dee San) re! 


bb uty erteesy. 3 amesave 
Ey: ee 4 

1602 afeijeye 
\.jaaBe ,eldsoricgs 

pi paazjeiveidda 
(4) 73S 


Cpisb tatjo oF oidedoiyvelea® 


2ic2 Jad soa stenvete 
‘eleao dfoidu .oe J 


fj 
a 3 


x spatotes Istedgizeq tas fanxeIRe 
ervnEsatei i eesxeta SlaisiuM: .eesdeasb 
| sholomk ed tiede pasesssord besudkrsale. 
o7 Benzyv qa isomessi7rb us Liswy eh iSsidsepls ud CY EE 
SiSe ypuepszems pial swollor oe 1% Deed 

+Imeht08) 


os eS 


a mapping of the components of the database to one 
another and to the files on which they will be 
recorded. 


Communications environment. This paragraph shall 


describe the 


data communications environment in which the database 
will be installed. Networks shall be described 
including specific information on the interface 
protocols. Reference may be made to other documents as 
applicable. 


Labeling conventions. This paragraph shall discuss the 
internal labeling conventions used in this database 
design document to the extent necessary to understand 
and use them. 


Organization of the database. This paragraph shall be 
divided into the following paragraphs to describe major 
design considerations for the organization of the 
database. 3.3.1 Conceptual model. This paragraph 
shall describe the conceptual model used for the 
database, portrayed by an appropriate charting 
technique such as an entity-relationship diagram. 


Physical allocation. This paragraph shall provide the 
information needed to ensure consistency of design 
concerning the organization and manipulation of the 
physical database areas/ files. The following 
information shall be provided for each area/file 
contained in the database: 


a. General area/file design and format 
lene Rationale for the design 
ce Inter-area/file dependencies of the area/file 


Special instructions. This paragraph shall contain 
instructions to be followed by personnel who will 
contribute to the generation of the database and who 
will use it for testing and operational purposes. Such 
instructions may include: 


a. Any specialized criteria for entering data into 


the database 


cor 


De Source documents for the rules and procedures to 
be followed 
when submitting data for entry into the database 


oe Source documents for the machine run instructions 
generating, modifying, updating, or otherwise 


using the database. In very large systems, where 
the details of such instructions are extensive, 
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this paragraph may reference sections of other 
documents where this specific information can be 
round. 


Support software available for handling the database. 
This paragraph shall identify and briefly discuss the 


Support software directly related to the database. 
Descriptions shall include software name, functions, 
Major operating considerations such as hardware setup 
and operating time, and references to detailed 
documentation. Examples of such software are: 


a. Database analysis software for reorganizing or 
changing the 
data 
be Database sizing software for initializing or 
resizing the 
database 
Ce Database loading software for moving or copying 
data 
as Database repairing software 


Security, privacy, and criticality. This paragraph 
shall contain an overview and discussion of the 


security, privacy and criticality considerations 
associated with the database. 


Database administrative information. This section 
shall provide the information necessary to establish 
and administer this database in the described 
environment. For purposes of this DID, the following 
terms are defined: 


a. Database administration: The process of defining, 
organizing, managing, controlling, and protecting 
a database. 


bY Schema: A description, or global model, of the 
SUruccunertoL 
a database. 


Cr Subschema: A subset of the schema that provides a 
complete 
description of a database from the perspective of 
a specific application. 


ar Logical data structure: A user’s view of the 
relationships 
among data elements ina database. This view may 
not reflect the actual form in which data are 
stored. 


e. Physical data structure: The form in which data 
are stored 
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on a medium. 


4.1 Responsibility. This paragraph shall identify the 
offices responsible for database administrative 
functions. 


4.2 System information. 


ees Database Management System (DBMS) configuration. This 

paragraph 
shall identify the Database Management System (DBMS) to 
be used and the vendor, version or release date, and 
targeted hardware of the DBMS. This paragraphs shall 
describe any restrictions on the initialization and use 
of the DBMS and capabilities of the DBMS to support any 
intended distributed processing. 


a2 42 Hardware configuration. This paragraph shall identify 
the 
hardware configurations on which the database can 
reside. 
a2. 3 Database software utilities. This paragraph shall list 
and 
reference the documentation of any DBMS utility 
software available to support the use or maintenance of 
the database. 
A224 Security and privacy. This paragraph shall describe 


the use and 
management of integrity and access controls that apply 
to all database components such as schema, subschemas, 
areas or physical files, records or tables, sets or 
relations, and data elements. 


4.3 Schema information. This paragraph shall be divided 
into the following subparagraphs to describe the 
overall structure to be reflected in the schema or 
other global definition of the database. 


BS. Rationale. This paragraph shall explain the rationale 
for the 
chosen database structure. 


Aros 2 Database content. This paragraph shall describe the 
content of 
the database, listing its data elements and indicating 
within which subschemas of the database they are 
visible. 


Mee ytd Description of schema and subschemas. This paragraph 
shall 


describe the schema and each subschema of the database, 
including name, file type and name, Data Description 
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4.3.4 
depict in 


ao sD 
depict in 


4.3.8 
provide a 


4.4.3 


Language, access control keys, concurrence locking, 
data name mapping, overall area/file limitations and 
controls, restrictions due to redefinitions and access 
paths, and any other limitations or restrictions. 


Logical structure. This paragraph shall describe and 
a 

chart the logical organization of the data into 
records, tuples, sets, or predefined relationships. 


Physical structure. This paragraph shall describe and 
a chart the physical structure (e.g., areas/files, 
indexes, pointers) of the logical components of the 
database. Methods for achieving operating efficiency 
shall be identified. 

Sizing. This paragraph shall provide sizing formulas 


determining the storage required to support the 
database content and associated software. 


Recovery. This paragraph shall describe the method for 


reestablishment or re-creation of the necessary schema 
and support files. 


Requirements cross-reference. This paragraph shall 


cross-reference to applicable requirements that are met 
by the database described in this document. 


Area/file information 
Rationale. This paragraph shall explain the rationale 
chosen physical structure of the database. 


Content of areas/files. This paragraph shall describe 


content of each area/file, listing the records it 
contains and explaining their purposes. 


Description of areas/files. This paragraph shall 


describe each 


4.4.4 
provide 


area/file, including name, type, code, mapping, 
limitations and controls, access procedures and 
mechanisms, and training or testing capabilities. 


Storage control parameters. This paragraph shall 


information about data storage and any limiting 
factors, such as allocation parameters and methodology, 
expansion methods, paging parameters, load criteria and 
limits, sizing procedures or formulas, and other 
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information that affects database storage. 
Recovery. This paragraph shall describe the method or 


documentation about the method to reconstruct the 
necessary data and structure. 


Use of the database by (identification of a CSCI or 
system). The purpose of this section is to provide 


technical information needed by applications developers 
to use the database and its utilities, procedures, 
processes, and structure in the development, 
Maintenance, or enhancement of software. When more 
than one CSCI or system will use the database, a 
separate section (Sections 5 through n) may be written 
for each 


Descriptions of the database. This paragraph shall be 
divided into the following subparagraphs to provide 


detailed technical descriptions of the database. 


(Identification of a subschema or local view). This 


shall identify the title or name of a subschema used by 
the system or CSCI and shall state its purpose. 


Records and their data elements. This paragraph shall 


describe each of the records in the subschema. The 
description shall provide name, code, size, and any 
other attributes needed to complete the description. 
This paragraph shall also list and describe the data 
elements that make up the record and their sources. 


Sets. This paragraph shall list and describe each of 


the sets or 


ees Xx 5 & 
each of 


= NEP Gree, 


predefined relations in the subschema. 

Areas/files. This paragraph shall list and describe 
areas/files of the database. Descriptions shall provide 
name, code, type, allocation, expansion, load factor, 
database keys, and page size. 

Access methods. This paragraph shall list and describe 
the unique access routines and query path structures 
that have been developed for this subschema or local 


view. 


Security and privacy. This paragraph shall describe 


the controls 


to be used to protect the subschema from unauthorized 
modification. 
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Database software utilities. This paragraph shall 
provide information regarding any utility software that 
has been developed to aid in database use for this CSCI 
or system. 


Error handling. This paragraph shall describe those 
error handling routines and procedures of the CSCI or 
system that are available during execution of database 
software. 


Messages. This paragraph shall provide a list of all 
messages output to the CSCI or system during execution 
of database software. 


Notes. This section shall contain any general 
information that aids in understanding this document. 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document, and a list of any terms and definitions 
needed to understand this document. If section 5 has 
been expanded into section(s) 6,...n, this section 
shall be numbered as the next section following section 
ne 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. Appendixes may be bound as 
separate documents for ease in handling. Appendixes 
shall be lettered alphabetically (A, B, etc.). 
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DOCUMENT: BLM C-80012B 


CONSOLIDATED SOFTWARE 
DESIGN DOCUMENT (C-SDD) 


Alternate For: 


System/Segment Document - BLM 80534B 
Software Design Document - BLM 80012B 
DataBase Design Document - BLM 80032B 


Interface Design Document - BLM 80027B 
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DOCUMENT: BLM C-80012B 


CONSOLIDATED SOFTWARE DESIGN DOCUMENT (C-SDD) 


PURPOSE: The Consolidated Software Design Document (C-SDD) is a 
Single document encompassing the design of a system, 
the design of each CSCI in the system, the design of 
the CSCI-external interfaces, and the design of each 
database in the system. 


CONTENTS: It contains, in summary form, the contents of the 
System/Segment Design Document (SSDD), Software Design 
Document(s) (SDDs), Interface Design Document (s) 
(IDDs), and Database Design Document(s) (DBDDs) for a 
project 


A C-SDD is written as an alternative to the individual 
design documents cited above. It is best suited toa 
project on which a single design document is most 
effective. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." 


4 Document Structure: 


ibe, Scope 
ew lLoentiri1cation 
1.2 System overview 
1.3 Document overview 
Ze Referenced documents 
oe System/segment design 
3.1 System/segment behavioral design 
.2 System architecture 
.3 Allocation of requirements 
.4 Processing resources 
5 Requirements traceability 
ftware (CSCI) design 
x (CSCI name and project-unique identifier). 
CSCI-wide behavioral design 
CSCI design conventions 
CSCI architectural design 
CSCI detailed design 
4.x.4.y (Software unit name and 
project - 
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3 
3 
3 
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unique identifier) 
A2ts5 Requirements traceability 
he Interface design 
5.1 Interface identification and diagrams 
i) 5.x (Interface name and project-unique 
identifier) 
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i Data elements 

2 Messages or other data assemblies 
ae Interface priorities 

4 Interface/communication protocols 


6.x (Database name and project-unique identifier) 


Gael Database overview 
Cox. 2 Database administrative information 
6vxes Use of the database by (CSCI or 
system 

identification) 


Notes 
Appendixes 
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Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this document. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


System/segment design. This section shall be divided 


into the following paragraphs to describe the design of 
a system or segment. 


System/segment behavioral design. This paragraph shall 


be divided into subparagraphs as needed to describe 
design decisions that transcend the internal structure 
of the system. It shall include, as applicable: 


a. Decisions on allowed/expected inputs/operations, 
including 
source, media, volume, frequency, sequence, 
priority, timing, format, units of measure, range 
of values, abbreviations, and codes 


i eye Decisions on planned behavior in response to each 
input/operation, including sequence, timing, 
selected equations/algorithms/rules, and handling 
of illegal inputs 


Cz Decisions on system displays, reports, etc., 
including 
formats, media, volume, frequency, priority, 
timing, recipients, forms, security, privacy, 
units of measure, range of values, abbreviations, 
and codes 
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a Decisions on system databases/data banks, 


including 


contents, size, records/entries, media, security, 
privacy, retention schedule, and names, synonyms, 
definitions, units, formats, range, abbreviations, 
and codes for the data elements 


e. Decisions on the type of flexibility and levels of 
availability, integrity, and confidentiality to be 
offered by the system 


System architecture. This paragraph shall be divided 
into subparagraphs as needed to provide the following 
information, using diagrams as needed: 


a. Describe the internal structure of the system, 


identifying 


the segments, HWCIs, and CSCIs and summarizing the 
purpose of each 


bt Describe the relationships among the segments, 


HWCIs, and 


CSCIs, including sequence of execution, as 
applicable 


ce Identify, state the purpose, and provide a high- 


description of each external interface of the 
system 


Allocation of requirements. This paragraph shall be 
divided into subparagraphs as needed to: 


a. Identify the system requirements allocated to each 
HWCI be Identify the system requirements allocated to 
each CSCI on Identify the system requirements 
allocated to each manual 
operation 
faba Identify the system requirements affecting each 
internal 
HWCI-to-HWCI interface 
e. Identify the system requirements affecting each 
internal 
HWCI-to-CSCI interface 
ee Identify the system requirements affecting each 
internal 


CSCI-to-CSCI interface 


Processing resources. This paragraph be divided into 
subparagraphs as needed to describe the processing 
resources to be used for the system. For each 
processing resource, this paragraph shall specify its 
hardware, programming, design, coding, and utilization 
characteristics, including for computer hardware: 
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Amount of internal memory 

Number of bits in each computer word 

Processing speed 

Character set standard 

Instruction set architecture 

Interrupt capabilities 

Direct Memory Access (DMA) capabilities 

Channel capacities 

Auxiliary storage capacities 

Growth capabilities 

Diagnostic capabilities 

Additional computer hardware capabilities 

- The allocation of pertinent processing resources 
o each 
CSCr 
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Requirements traceability. This paragraph shall 
provide traceability from the system requirements to. 


the HWCIs, CSCIs, and manual operations of the system, 
to demonstrate that each system requirement has been 
allocated. The traceability may be shown in a table. 


Software (CSCI) design. This section shall be divided 


into the following paragraphs to describe the design of 
one or more CSCIs. 


(CSCI name and project-unique identifier). 


CSCI-wide behavioral design. This paragraph shall be 
into subparagraphs as needed to describe CSCI design 
decisions that transcend the internal structure of the 
CSCI. It shall include, as applicable: 


a. Decisions on allowed/expected inputs from users 


and other 


sources, including name(s), source, media, volume, 
frequency, sequence, priority, timing, security, 
privacy, format, units of measure, range of 
values, abbreviations, codes, examples 


DF Decisions on planned behavior in response to each 
sRaveibhep 
including actions, sequence, conditional behavior, 
timing, selected equations/algorithms/rules, 
disposition, and handling of illegal or "out-of- 
bounds" inputs 
a Decisions on CSCI-produced outputs (displays, 
reports, 


etc.), including name(s), format/layout, media, 
volume, frequency, priority, timing, recipients, 
forms, security, privacy, units of measure, range 
of values, abbreviations, codes, disposition, 
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examples 


a. Decisions on CSCI-contained databases/data banks, 
including 

(1) contents: size, records/entries, media, 
security, privacy, retention; (2) data elements: 
name(s), definitions, units, formats, range, 
abbreviations, security, privacy, codes for the 
data elements; (3) relationship to CSCI 
capabilities/functions; (4) data 
retention/reporting. Reference may be made to 
Database Design Documents. 


e. Decisions on the type of flexibility and the 
levels and 
types of availability, security, privacy, and 
continuity of operations to be offered by the CSCI 


(Ne eg CSCI design conventions. This paragraph shall explain 
any rules, 
schemes, and conventions used in designing the CSCI and 
expressing that design. Design standards may be 
referenced. This information shall include, as 


applicable: 
a. Mnemonic identifiers and their use 
be Conventions for design diagrams, listings, 
abbreviations, 
comments, and symbols appearing in diagrams and 
listings 
Cc. Standard data elements and related features 
4.Xx.3 CSCI architectural design. This paragraph shall be 


divided into 
subparagraphs as needed to present the following 
information. The information may be presented 
graphically, for example in diagrams, tables, or flow 


charcs* 
a The role of the CSCI within the system 
architecture, 
including the purpose of each CSCI-external 
interface 
DD. The internal architecture of the CSCI, including 


the 
following, annotated to identify differences for 
each state and mode in which the CSCI operates: 


1) The name/ID and purpose of each software unit 
comprising the architecture 


2) The structure of the CSCI, including, as 
applicable: 
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software 


a) The flow of execution control among 


units, including any dynamically 
controlled sequencing during the CSCI’s 
operation 

b) The flow of data among software units 


By Any non-developmental software to be 


incorporated into 


to the 


ax. 4 
into the 


4.x.4.y 
This 


in the 


the CSCI 
4) The allocation of memory and processing time 
software units 
CSCI detailed design. This paragraph shall be divided 


following subparagraphs to provide a design description 
of each software unit of the CSCI. The information 
may be presented graphically, for example in diagrams, 
tables, or flow charts; in a program design language; 
or by reference to other design representations 
including headers of the code. 


(Software unit name and project-unigue identifier). 


paragraph shall identify a software unit by name and 
project-unique identifier. Alternatively, it may 
identify a group of software units, with each software 
unit identified in a subparagraph. The design 
description of each software unit shall include the 
following, as applicable: 


a. The purpose of the software unit 
De The requirements allocated to the software unit 
Cr The derived design requirements for the software 
Chace (Wenge pep 
the algorithms to be incorporated into the 
software unit) 
dq Any constraints, limitations, or unusual features 


design of the software unit 
e. The programming language and rationale if 
different from 

chateror-the CSCI 
£5) Reusable software to be used, where it resides, 


where its design is documented 


co The program library in which the software unit is 


to be 


placed 
he The inputs, outputs, and other data elements of 


the software 


unit, including, as applicable for each: 
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2) Project-unique identifier 
20 Brief description including purpose 
3) Units of measure, such as knots, seconds, 


meters, 
dollars 
4) . Limit/range of values (for constants, the 
actual value) ey Accuracy 
6). Precision/resolution in terms of significant 
digits 7) Priority 
8) Frequency at which the data element is input, 
calculated, refreshed, or output 
9) Legality checks to be performed on the data 
element 10) Data type, such as integer, ASCII, 
fixed, real, 
enumeration 
11) Data representation/format/structure 
12) Sources, including other software units where 
the data 


element is set 
13) Destinations, including other software units 
where the 
data element is used 
14) Maximum size and storage needs 
15) Access method, such as random or sequential 


a. The logic flow to be used by the software unit, 
including: 
1) Conditions under which software unit 
execution is initiated 
2) Conditions under which control is passed to 
other 
software units 
3) Response and response time to each input 
4) Dynamically controlled sequencing 
during the software 
unit’s operations 


4.x.5 Requirements traceability. This paragraph shall 
provide 


traceability from the CSCI requirements to the software 
units. The traceability may be shown in a table. 


5 Interface design. This section shall be divided into 
the following paragraphs to describe the design of one 
or more CSCI-external interfaces, that is, the specific 
interface characteristics selected to respond to the 
CSCI-external interface requirements. If part of all 
of this information is documented elsewhere, it may be 
referenced. 


ay Interface identification and diagrams. This paragraph 
shall identify and provide an overview of each 


interface between the CSCIs to which this document 
applies and other HWCIs, CSCIs, and critical items. 
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This description may be provided by one or more 
interface diagrams, as appropriate, and shall 
characterize each interface (sequential or concurrent 
operation, real-time data transfer, store-and-retrieve 
data transfer, operator controlled, etc.) 


(Interface name and project-unigque identifier). This 
paragraph (beginning with 5.2) shall identify an 
interface by name and project-unique identifier and 
shall state its purpose. This paragraph shall be 
divided into the following subparagraphs. 


Data elements. This paragraph shall provide, possibly 
element definition table, the following information, as 


applicable, for each data element transmitted between 
the interfacing items: 


a. A project-unique identifier for the data element 
De A brief description of the data element 
cr. The CSCI, HWCI, or other item that is the source 
of the data 
element 
a: The CSCI(s), HWCI(s), or other item(s) that are 
the 
recipients of the data element 
e. The units of measure of the data element, such as 
seconds, 
meters, dollars 
ie The limit/range of values of the data element (for 
constants, provide the actual value) 
g. The accuracy of the data element 
, ial The precision or resolution of the data element in 
terms o 


Sos 


Significant digits 
ai The timing characteristics of the data element, 


for example, 


pass 


real, 


how often sent or received, how long transmitted 


cn Legality checks the data element must be able to 
The data type, such as integer, ASCII, fixed, 
enumerated 

ie The data representation/format 

m. The sequence and other dependencies of the data 

element 


Messages or other data assemblies. This paragraph 


shall identify 


by name and project-unique identifier each message or 
other assembly of data elements transmitted between the 
interfacing items, and shall describe the assignment of 
data elements to each message or assembly. A cross- 
reference of each message or assembly to the data 


, eny 


elements it contains, and vice versa, shall be 


provided. 
See Oe Interface priorities. This paragraph shall specify the 


relative 
priority.of the interface and of each data element, 
message, or assembly transmitted between the 
interfacing items. 


Baxc4 Interface/communication protocols. This paragraph 
shall be 


divided into subparagraphs as needed to describe the 
commercial, military, or proprietary communications 
protocols associated with the interface. Each protocol 
shall be identified and described, including the 
following, as applicable: 


ai Fragmentation and reassembly of messages 

be Message formatting 

Ck Legality checks, error control and recovery 
procedures, 


including fault tolerance, handling of "out-of- 
bounds" conditions, and features to ensure 
continuity of operations in the event of 


emergencies 

d. Synchronization, including connection establishment, 
maintenance, termination, and timing 

e. Flow control, including sequence numbering, window 


size, and 
buffer allocation 


I Data transfer rate, whether periodic/aperiodic, 
minimum 

interval between transfers 
Gi Routing, addressing, and naming conventions 
h. Transmission services, including priority and 
grade i. Status, identification, notification, and any 
other 

reporting features 
pe Security and privacy, including encryption, user 


authentication, compartmentalization, and auditing 


6. Database design. This section shall be divided into 
the following paragraphs to describe the logical and 
physical design of one or more databases. 


6.x (Database name and project-unique identifier). 
Ge xX. 1 Database overview. This paragraph shall be divided 
into 


subparagraphs as needed to provide the following 
overview information about the database: 


a. Database environment: 
1) Identification of systems that will use the 
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database 2 Relationship to other databases, 
including supersession 3) Estimated internal and 
peripheral storage requirements, 

including variations for different modes of 


operation 
4) . Mapping of database components to one another 
and to 
the files on which they will be recorded 
5) Data communications environment in which the 
database 


will be installed 


by Internal labeling conventions used in this 
database design 


Ge Organization of the database and major design 
considerations: 
a) The conceptual model used for the database 
2} Physical allocation, including for 
each area/file: a) General 
area/file design and format 
b) Rationale for the design 
Cc) Inter-area/file dependencies of the 
area/file 


a: Instructions to be followed by personnel who will 
contribute 
' to the generation of the database and who will use 
TtefoEr 
testing and operational purposes, including, as 
applicable: 


aly) Any special criteria for entering data into 
the data- 
base 
2) Source documents for the rules/procedures for 
submitting data for entry 
3) Source documents for the machine run 
instructions for 
generating, modifying, updating, or otherwise 
using the database 


e. Support software available for handling the 
database (such 
as database analysis/ sizing/loading/repairing 
software), including name, functions, major 
operating considerations, and documentation 


references 
1a Overview of security, privacy and criticality 
considerations 


for the database 


ep, ee Database administrative information. This paragraph 
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shall be 


divided into subparagraphs as needed to provide the 
information necessary to establish and administer the 
database in the described environment. It shall 
include, as applicable: 


a Identification of the offices responsible for 


database 


administrative functions 


br System information, including: 


ag) 
release date, 


The identification, vendor, version or 


and targeted hardware of the Database 
Management System (DBMS) to be used 


Pay) Hardware configurations on which the database 
can 
reside : 
a) Identification and document references for 
any DBMS 
utility software 
4) Use and management of integrity and access 
controls 
CA Schema information, including: 
1) Rationale for the chosen database structure 
2) Content of the database, listing its data 
elements and 
indicating within which subschemas of the 
database they are visible 
3) Description of schema and each subschema of 
the 
database, including name, file type and name, 
Data Description Language, access control 
keys, concurrence locking, data name mapping, 
overall area/file limitations and controls, 
restrictions due to redefinitions and access 
paths, and any other limitations or 
restrictions 
4) Logical organization of the data into 
records/tuples/ 
sets/predefined relationships 
5) Physical structure (e.g., areas/files, 
indexes, 
pointers) and methods for achieving operating 
efficiency 
6) Sizing formulas for determining required 
storage Th Recovery methods for 
reestablishing schema and support 
files 
8) Cross-reference to applicable requirements 
d. Area/file information, including: 
a Rationale for the chosen physical structure 


2) 
records it 

3) 
name, type, 

4) 


limiting factors 


Content of each area/file, listing the 


contains and their purposes 
Description of each area/file, including 


code, mapping, limitations and controls, 
access procedures/mechanisms, and 
training/testing capabilities 


Information about data storage and any 


regarding allocation, expansion, paging, 
loading, size 


5) Recovery methods for reconstructing the 
necessary 
data and structure 
Sox .-3 Use of the database by (CSCI or system identification). 
This 


paragraph shall be divided into subparagraphs as needed 
to provide technical information needed by applications 
developers to use the database and its utilities in the 
development, maintenance, or enhancement of software. 
When more than one CSCI or system will use the 


database, 


additional paragraphs similar to this one 


shall be added. Each shall include, as applicable: 


Qi Detailed technical descriptions of the database, 


including 


the name and purpose of each subschema or local 
view, and for each: 


i) 
subschema, 
2) 
predefined 
3) 
the 
4) 


and query 


5) 
POntrols. ror the 


A list and description of each record in the 


including name, code, size, other needed 
attributes, and description of data elements 
in the record 

A list and description of each set or 


relation in the subschema 
A list and description of any areas/files of 


database, including name, code, type, 
allocation, expansion, load factor, database 
keys, and page size 

A list and description of each access routine 


path structure developed for this subschema 
or local view 
A description of security and privacy 


subschema 


ist Information about utility software to aid in 
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database use 


& for this CSCI or system 
= A description of any error handling routines and 
procedures 
available 
cs A list of all messages output to the CSCI during 
execution 


of database software 


Las Notes. This section shall contain any general 
information 
that aids in understanding this document (e.g., 
background information, glossary, rationale). This 
section shall contain an alphabetical listing of all 
acronyms, abbreviations, and their meanings as used in 
this document, and a list of any terms and definitions 
needed to under* stand this document. 


2 Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT: BLM 80029B 
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’ SOFTWARE PRODUCT SPECIFICATION (SPS) 


PURPOSE: The Software Product Specification (SPS) provides 
information needed to understand and support the 
software product. 


CONTENTS: This document contains or references the Computer 
Software Configuration Items (CSCIs), the source code 
listings for the CSCI, the compilation/build procedures 
needed to convert the source code into executable code, 
information on the CSCI’s resource utilization, and 
procedures required to modify the CSCI. 


Upon Government approval, the design information and 
source code listings included in or referenced from the 
SPS establish the Product Baseline for the CSCI. They 
are also used to establish the Product Baseline for the 
system. 


Paragraphs that have been tailored out of the DID shall 

result in the corresponding paragraph number and title 

in the document, followed by "This paragraph has been 
BD, tavloredrout.* 


Document Structure: 


ve Scope 

iVieatdentilication 

1.2 System overview 

1.3 Document overview 
2% Applicable documents 

2.1 Government documents 

2.2 Non-Government documents 
35 Requirements 

3.1 Software design 


3.2 Source code listings 
3.3 Compilation/build procedures 
3.4 Measured resource utilization 
3.5 Modification procedures 

4. Notes 

Dr Appendixes 


Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCI to which this 
document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of the document. 


Applicable documents. This section shall be divided 
into the following paragraphs. 


Government documents. This paragraph shall contain a 
list of each Government documents reference within this 
document and shall be identified by Identification 
Number, Document Title, date of publication, and author 
(if known). 


Non-Government documents. This paragraph shall contain 
a list of each Non-Government documents reference 
within this document and shall be identified by 
Identification Number, Document Title, date of 
publication, and author (if known). 


Requirements. This section shall be divided into the 
following paragraphs. 


Software design. This paragraph shall contain, or 
reference an appendix or other deliverable document 
that contains, information describing the design of the 
"as-built" (delivered) CSCI. The information shall be 
the same as that required in a Software Design Document 
(SDD), Interface Design Document (IDD), and Database 
Design Document (DBDD), as applicable. If these 
documents or their equivalents are to be delivered for 
the "as-built" CSCI, this paragraph shall reference 
them. If not, the information shall be provided in 
this document. Information provided in the headers, 
comments, and code of the source code listings may be 
referenced and need not be repeated in this section. 

If the SDD, IDD, or DBDD is included in an appendix, 


the paragraph numbers and page numbers need not be 
changed. 


Source code listings. This paragraph shall contain, or 
reference an appendix that contains, the source code 
listings for the CSCI. This paragraph shall provide an 
index cross-referencing each software unit to the 
location of the listings where the code corresponding 
to that unit can be found and any comments useful in 
accessing or interpreting the listings. 


Compilation/build procedures. This paragraph shall 


describe, or reference an appendix that describes, the 
compilation/build process used to create the executable 
software product from the source code. It shall 
specify the compiler(s)/assembler(s) used; other 
hardware and software needed; any settings/options/ 
conventions used; and procedures for compiling/ 
assembling, linking, and building the CSCI and the 
software system/subsystem containing the CSCI, 
including variations for different sites, 
configurations, versions, etc. Build procedures above 
the CSCI level may be presented in one SPS and 
referenced from the others. 


Measured resource utilization. This paragraph shall 
specify the measured resource utilization of the CSCI 
at the time of delivery. 


Modification procedures. This paragraph shall describe 
procedures that must be followed to modify the CSCI. 

It shall include or reference information on the 
following, as applicable: 


ay Support facilities, equipment, and software, and 
procedures 
for their use 


lah Databases/data banks used by the CSCI and 
procedures for 
using them 


CE Design or coding conventions to be followed 


ol Compilation/build procedures if different from 
those above 


e. Integration and testing procedures to be followed 
ae Error conditions, and procedures for responding to 
them 


Notes. This section shall contain any general 
information that aids in understanding this 


specification (e.g., background information, glossary, 
formula derivations). This section shall include an 
alphabetical listing of all acronyms, abbreviations, 
and their meanings as used in this document and a list 
of any terms and definitions needed to understand this 
document . 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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SOFTWARE DEVELOPMENT PLAN (SDP) 


PURPOSE: The Software Development Plan (SDP) describes a contractor’s 
plans for conducting a software development effort. The term 
"development" in this DID is meant to include creating new items, 
incorporating existing items, updating or refining existing 
items, or a combination of these approaches. 


It is used to provide the Government insight into, and a tool for 
monitoring, the processes to be followed for software 
development, the methods to be used, the approach to be followed 
for each activity, the schedules for the project, and project 
organizations and resources. 


CONTENTS: This Data Item Description (DID) contains the format and content 
to describe the Software Developer’s plan to complete the 
software development project and doing so while remaining in 
compliance with the Bureau Standards for software development. 


Alternate presentation styles. Charts, tables, matrices, and 
other presentations styles are acceptable substitutes for text 
when data required by this DID can be made more readable using 
these styles. 


) Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." 


DOCUMENT STRUCTURE: 


L. Scope 
1.1 Identification 
1.2 System overview 
1.3 Document overview 
1.4 Relationship to other plans 
Referenced documents 
Overview of the work to be done 
‘ Complying with 77-SDS-000102 general requirements 
4.1 Software development process 
4.2 General plans for software engineering. 
.2.1 Software development methods 
2.2 Reusable software 
2.3 Safety analysis 
2.4 Processing resource and reserve capacity 
.2.5 Recording rationale 
ner 
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- Testing on target computer system 
Se Complying with 77-SDS-000102 detailed requirements 
® 5.1 Project planning 

5.2 Establishing a software development environment 
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System requirements analysis 

Software requirements analysis 
Software architectural design 

Software detailed design 

Coding and unit testing 

Unit integration and testing 

CSCI testing 

CSCI integration and testing 

System testing 

Preparing for software use and support 
Preparation for software delivery 
Software product evaluations 

Software configuration management 
Corrective action and process improvement 
Joint reviews 

Other software development activities 


Schedules 
Project organization and resources 


ipl 


Notes 


Project organization 


Appendixes 


f 


: Scope. This section shall be divided into the following 
® paragraphs. 
ita Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which this document 
applies, including, as applicable, identification number(s), 
title(s), abbreviation(s), version number(s), and release 
number(s). 


2 System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
Maintenance; identify the project sponsor, user, developer, and 
Support agencies; identify current and planned operating sites; 
and list other relevant documents. 


x Msp Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


1.4 Relationship to other plans. This paragraph shall describe the 
relationship, if any, of the SDP to related project management 
plans. 

2s Referenced documents. This section shall list by document number 
and title all documents referenced in this plan. This section 

& shall also identify the source for all documents not available 


through normal Government stocking activities. 


a Overview of the work to be done. This section shall be divided 
into paragraphs as needed to provide an overview of the work to 
be accomplished and to establish the context for the planning 
described in later sections. It shall include, as applicable, 
contractual and other requirements and constraints regarding: 


ae The system and software to be developed 
b. The documentation required 
Cx Overview of the system life cycle and the position of the 


project within that life cycle 


ds The software life cycle model to be used 
e. Project schedules and resources 
fe Other aspects of the project, such as security, privacy, 


methods, standards to be followed, testing constraints, etc. 


Complying with 77-SDS-000102 general requirements. This section 
shall be divided into the following paragraphs. Provisions 


corresponding to non-required activities may be satisfied by the 
words "Not applicable." In addition to the content specified 
below, each paragraph shall identify applicable 
risks/uncertainties and plans for dealing with them. 


Software development process. This paragraph shall describe the 
software development process to be used to develop the software. 
It shall include, as applicable: 


as. A proposed life cycle model for the software if none is 
established in the contract, that is, a set of phases, 
builds, increments, blocks, or other project stages for the 
software, and the objectives of each. (Note: The remainder 
of this DID uses the term "build;" this term should be 
interpreted to suit the project) 


Dé A mapping of the activities required by 77-SDS-000102 (and 
other contract provisions) onto that portion of the software 
life cycle model covered by the contract, that is, 
identification of the activities to be performed in each 
build and, as applicable, their relationships to one another 


General plans for software engineering. 


Software development methods. This paragraph shall describe the 
software development methods to be used. Included shall be 
descriptions of the manual and automated tools and procedures to 
be used in support of these methods. Reference may be made to 
other paragraphs in this plan if the methods are better described 
in context with the activities to which they will be applied. 


Reusable software. This paragraph shall describe the approach to 
be followed for identifying, evaluating, and incorporating 
reusable software into software required on this project. 
Candidate or selected reusable components known at the time this 
plan is prepared shall be identified and described, together with 
benefits and drawbacks, as applicable, for their use. 


Safety analysis. This paragraph shall describe the approach to 
be followed for ensuring that the requirements, design, code, and 
operating procedures minimize or eliminate the potential for 
hazardous conditions during the operational mission. 


Processing resource and reserve capacity. This paragraph shall 
describe the approach to be followed for analyzing, allocating, 


and monitoring the processing resource and reserve requirements 
established for the software. 


Recording rationale. This paragraph shall describe the approach 


to be followed for recording the rationale for key decisions made 
in specifying, designing, implementing, and testing the software. 


General plans for software testing. 
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Independence in testing activities. This paragraph shall 
describe the approach to be followed for achieving the required 
level of independence in testing activities. 


Testing on target computer system. This paragraph shall describe 
the approach to be followed for including testing on the target 


computer system or an equivalent system approved by the 
contracting agency as part of CSCI, CSCI integration, and system 
testing. 


Stress testing. This paragraph shall describe the approach to be 
followed for stressing the software at the limits of its 
specified requirements as part of CSCI, CSCI integration, and 
system testing. 


Complying with 77-SDS-000102 detailed requirements. This section 
shall be divided into the following paragraphs. Provisions 


corresponding to non-required activities may be satisfied by the 
words "Not applicable." The discussion of each activity shall 
include the approach (methods/procedures/tools) to be applied to 


1) the analysis or other technical tasks involved, 
2) the recording of results, and 


3) the preparation of associated deliverables, if applicable. The 
discussion shall also identify applicable risks/uncertainties and 
plans for dealing with them. Reference may be made to 4.2.1 if 
applicable methods are described there. 


Project planning. This paragraph shall describe the approach to 
be followed for developing project plans in each build. Included 
shall be the approach for: 


a. Further development of this software development plan 

b. Planning CSCI and CSCI integration testing 

Cc. Performing or participating in planning system testing 

a; Planning for transition to software support 

e. Planning for software installation and training at the user 


Sites specified in the contract 


Establishing a software development environment. This paragraph 
shall describe the approach to be followed for establishing, 


controlling, and maintaining a software development environment 
in each build. Included shall be descriptions of: 


a. The software engineering environment: its elements; 
Government rights to those elements; plans for establishing, 
testing, controlling, and maintaining the environment 


GOLSvaD Stew IZC® & erntce 


au 


“ies 2.0 .aobtksbdoa pa) ied. ok apmaiaeraat 
sitse x03 bewakieeone ee 4 wOmNTGs ota wd fo. 
eeicivisjos pithtees ©! eaonabseqebak Ge level 


Ja43 Loe es eo orth mee 
107 bewolind ad of dsséaqgs. oes 
ymisviuos 6 %O MevsYa Petteiag 
< i GA “SPeps PA Jo6e798ee 

. meliges 


| | ait UIFS) tenes 
—wlaj3uct Bewoelies 

. ; zi : tlvpey Dbeil loa 
i983 aeons 


r =) oF« aA 

7 ri bay Low i ine 
MZ CCCRSeTICH 

1G@ Str” ebro 

‘TS 7. oP Slory 


; "Ts = is 
6 tiartke ondgeuoars 
tw por losh vel Gaile 
MI & Laaoas Lacs 


=e a. See *( a 
re 7 » it met t D> aa 


> , @ | 'ecta 


i ‘ i Tis 
p r. ne 
: {Lo LTisPQ. t9 Listed 2) 
: 80i3 : 107 paren 1% 


eJani « jeer 


ino. « be cl Loeg@ ab3i« 


m vi USS Lawes . oo eats Scie Sens 1G 5-288 

( 1 86 Go froeR te ect mit ?>a&s lian 
: 6 ban .gititossceg 
mNoizatsseeb od-tiate s elses vliog dose “ail 


21 . Jnemeostyoe Coizeun! pom skeytiou oT ca 
‘eli; ;asntemeatle eaots 53 actdy es STEIT VOD _ 
287 polnisdatam box eat t Lepeaeae i aie : 


Ds The software test environment: its elements; Government 
rights to those elements; plans for establishing, testing, 
controlling, and maintaining the environment (reference may 
be made to the Software Test Plan) 


(om The software development library: its elements, plans for 
establishing and maintaining the library, and planned access 
controls 

a’ Software development files: their format, content, and plans 


for their creation and maintenance 


e. Design and coding standards to be used 
pas Non-deliverable software to be used 
g. Any other software standards and procedures to be used 


System requirements analysis. This paragraph shall describe the 
approach to be followed for performing or participating in system 
requirements analysis in each build. Included shall be the 
approach for: 


a. Analyzing user input 
Ds Defining the operational concept 
G), Defining the system requirements 


System design. This paragraph shall describe the approach to be 
followed for performing or participating in system design 
analysis in each build. Included shall be the approach for: 


a. Developing the system behavioral design 
Ds Developing the system architectural design 


Software requirements analysis. This paragraph shall describe 
the approach to be followed for software requirements analysis in 


each build. Included shall be the approach for: 


an Defining the CSCI engineering (and corresponding 
qualification) requirements 


b. Defining the CSCI interface (and corresponding 
qualification) requirements 


Software architectural design. This paragraph shall describe the 
approach to be followed for performing software architectural 
design in each build. Included shall be the approach for: 


ae Developing the CSCI behavioral design 
br Developing the CSCI architectural design 
(al A Developing the database logical design 


Software detailed design. This paragraph shall describe the 
approach to be followed for performing software detailed design 
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in each build. Included shall be the approach for: 


a. Developing the CSCI detailed design 
b. Developing the CSCI interface design 
oie Developing the database physical design 


Coding and unit testing. This paragraph shall describe the 
approach to be followed for coding and unit testing in each 
build, including the programming language(s) to be used. Included 
shall be the approach for: 


a. Coding software units 

lee Populating those databases to be populated as part of 
software development 

C. Preparing for unit testing 

ae Performing unit testing 

e. Revision and retesting based on test results 

ce Recording unit test results 


Unit integration and testing. This paragraph shall describe the 
approach to be followed for unit integration and testing in each 
build. Included shall be the approach for: 


a. Preparing for unit integration and testing 

D. Performing unit integration and testing 

OF Revision and retesting based on test results 

Gh Recording unit integration and test results 

ESCletesting ; This paragraph shall describe the approach to be 


followed for CSCI testing in each build. Included shall be the 
approach for: 


a. Preparing CSCI test cases 

lox Preparing CSCI test procedures 

ve, Dry run of CSCI test procedures 

a Performing CSCI testing (including Government witnessed 
testing, as applicable) 

e. Revision and retesting based on test results 

ae Analyzing and recording CSCI test results 

on Updating CSCI test cases and procedures 

CSCI integration and testing. This paragraph shall describe the 


approach to be followed for CSCI integration and testing in each 
build. Included shall be the approach for: 


a. Preparing CSCI integration and test cases 
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Ds Preparing CSCI integration and test procedures 
Cc Dry run of CSCI integration and test procedures 


d. Performing CSCI integration and testing (including 
Government witnessed testing, as applicable) 


e. Revision and retesting based on test results 

5. Analyzing and recording CSCI integration and test results 
Gs Updating CSCI integration and test cases and procedures 
System testing. This paragraph shall describe the approach to 


be followed for performing or participating in system testing in 
each build. Included shall be the approach for: 


as Preparing system test cases 

be Preparing system test procedures 

ous Dry run of system test procedures 

el Performing system testing (including Government witnessed 


testing, as applicable) 


e. Revision and retesting based on test results 
ie Analyzing and recording system test results 
Gn Updating system test cases and procedures 


Preparing for software use and support. This paragraph shall 
describe the approach to be followed for preparing for software 


use and support in each build. Included shall be the approach 
rox: 


a. Developing software user manuals 

jole Developing computer center software operator manuals 

cA Developing software input/output manuals 

oe Developing computer system operator manuals 

e. Developing computer instruction set architecture manuals 
1 Developing firmware support manuals 

sie Performing installation and training at user sites 


(reference may be made to the Software Installation Plan) 


he Transitioning software and environments to the designated 
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Support site (reference may be made to the Software Support 
Plan) 


Preparation for software delivery. This paragraph shall 


describe the approach to be followed for preparing for software 
delivery in each build. Included shall be the approach for: 


as Preparing executable code for delivery 

b. Preparing source code for delivery 

ce Developing software product specifications 
d. Developing version descriptions 

e. Supporting Functional Configuration Audit (s) 
1k Supporting Physical Configuration Audit (s) 


Software product evaluations. This paragraph shall describe the 
approach to be followed for performing software product 
evaluations of contractor and subcontractor products in each 
build. Included shall be the approach for: 


a. Performing in-process software product evaluations, 
including items to be evaluated, sampling methods for 
software development files, and any proposed alternatives or 
additions to the criteria and definitions in 77-SDS-000102 


be Performing final software product evaluations, including 
items to be evaluated and any proposed alternatives or 
additions to the criteria and definitions in 77-SDS-000102 


ce Achieving the required independence in software product 
evaluation activities 


d. Preparing and maintaining software product evaluation 
records, including items to be recorded 


Software configuration management. This paragraph shall describe 
the approach to be followed for performing software configuration 


Management in each build. Included shall be the approach for: 


a. Controlling development products, including: 
a) Configuration identification of development products 
2) Configuration control of development products, 


including, as applicable: 


a) The levels of control each product must pass 
through 


b) Persons/groups who can authorize and make changes 
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at each level 


Cc) Procedures for requesting authorization, 
processing each request, tracking changes, and 
maintaining past versions 


bs Interface with Government Configuration 
Management, including: 


i) Using Engineering Change Proposals 

2) Configuration status accounting, including 
the format, content, and purpose of reports 
to be used 


Cu Storage, handling, and delivery of project media 


Corrective action and process improvement. This paragraph shall 
describe the approach to be followed for performing corrective 
action and process improvement in each build. Included shall be 
the approach for: 


a. Preparing problem/change reports, including the items to be 
included in each report (candidate items include project 
name, originator, problem number, problem name, software 
element or document affected, origination date, category and 
priority, description, analyst assigned to the problem, date 
assigned, date completed, analysis time, recommended 
solution, impacts, problem status, approval of solution, 
follow-up actions, corrector, correction date, version where 
corrected, correction time, description of solution 
implemented) 


Db; Implementing a corrective action and process improvement 
system 


Joint reviews. This paragraph shall describe the approach to be 
followed for holding joint (customer/contractor) reviews in each 
build. Included shall be: 


a. A proposed set of technical-level reviews, including the 
items to be reviewed, objectives to be achieved, and 
preparatory and follow-up activities for each review 


Ds A proposed set of management-level reviews, including the 
items to be reviewed, objectives to be achieved, and 
preparatory and follow-up activities for each review 


Software development management. This paragraph shall describe 
the approach to be followed for performing software development 
management in each build. Included shall be the approach for: 


a. Risk management, including a discussion of the technical, 
cost, and schedule risks identified for the project and 
plans for dealing with them (if all applicable risks have 
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been covered in the activity planning, this paragraph may so 


state.) 

ley Complying with the security and privacy requirements in the 
contract 

c. Managing subcontractors 

he Interfacing with software IV&V agents 

e. Coordinating software development efforts to ensure 


compatibility at interfaces with associate contractors 


Ee: Applying management indicators, including the indicators to 
be used, the data to be collected, the methods to be used to 
interpret and apply the data, and the reporting mechanism to 
be used 


Other software development activities. This paragraph shall 
describe the approach to be followed for performing any other 


software development activities in each build. 


Schedules. This section shall present the schedule(s) for the 
Progect: Tait shalloinclude: 


a. Schedule(s) identifying the activities in each build and 
showing initiation of each activity, availability of draft 
and final deliverables and other milestones, and completion 
of each activity 


br An activity network, depicting sequential relationships and 
dependencies among activities and identifying those 
activities that impose the greatest time restrictions on the 
project 


Project organization and resources. This section shall be 
divided into the following paragraphs to describe the project 


organization and resources to be applied in each build. 


Project organization. This paragraph shall describe the 
organizational structure to be used on the project, including the 
organizations involved, their relationships to one another, and 
the authority and responsibility of each organization for 
carrying out required activities. 


Project resources. This paragraphs shall describe the resources 
to be applied to the project. It shall include, as applicable: 


a. Personnel resources, including: 


1) The estimated staff-loading for the project (number of 
personnel over time) 
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“2 The breakdown of the staff-loading numbers by 
responsibility (for example, management, software 
engineering, software testing, software configuration 
management, software product evaluation) 


3) An overview of the skill levels, geographic locations, 
and security clearances of personnel performing each 
responsibility 

b. Overview of contractor facilities to be used, including 


geographic locations in which the work will be performed, 
facilities to be used, and secure areas and other features 
of the facilities as applicable to the contracted effort. 


ie Government furnished equipment, software, services, 
documentation, data, and facilities required for the 
contracted effort. A schedule detailing when these items 
will be needed shall also be included. 


ds. Other required resources, including a plan for obtaining the 
resources, dated needed, and availability of each resource 
item. 


Notes. This section shall contain any general information that 
aids in understanding this document. This section shall include 
an alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., Charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 


- ~ 
v1 2 


ibs? Sa awI70s 


v 7 ‘ H 

PouUDoOTY Sows Oe 
. f bs es ony } 5 
- 

, 

a ‘3 

° 
n : 


Slete aly to nwobdsesd “at: 
sfomeaee Yok) yitildtesoqes 


iw | 
| ca i 
; ra ,) 


a 


puivsert 
a om trenroens 


aivisvo fA 
‘thxuose Gas 
i via nageax 


to waivievo, - 

| nS iqstpoye 

xd of eelititog 
bili tess 283 26 


‘aT sdemtrrsevoo 
JHenssooD 


DOCUMENT NO: BLM C-80030B 
CONSOLIDATED SOFTWARE PLAN (C-SP) 


Alternate For: 


Software Development Plan - BLM 80030B 
Software Support Plan - BLM 80033B 
Software Installation Plan - BLM 80032B 
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DOCUMENT NO: BLM C-80030A 


PURPOSE: 


CONTENTS : 


CONSOLIDATED SOFTWARE PLAN (C-SP) 


The Consolidated Software Plan (C-SP) is a single document 
encompassing the planning for software development, software 
installation, and preparation for transition to software support. 


It contains, in summary form, the contents of the Software 
Development Plan (SDP), Software Installation Plan (SIP), and 
Software Support Plan (SSP). 


A C-SP is written as an alternative to the individual planning 
documents cited above. It is best suited to a project on which a 
Single planning document is most effective. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." 


Document Structure: 


Lee Scope 
a eidentification 
1.2 System overview 
1.3 Document overview 


vi Referenced documents 
3% Software development planning 
3.1 Overview of the work to be done 
3.2 Complying with 77-SDD-000102 general requirements 
3.3 Complying with 77-SDD-000102 detailed requirements 
3.4. Schedules 
3.5. Project organization and resources 
4. Software installation planning 
4.1 Installation overview 
4.2 Site information for computer operations personnel 
aS 2ex (Site Name). 
4.3. Site information for user personnel 
4.3.x (Site Name) 
ae Software support planning 
SOLE Ware  SuppOrc) resources 
5.2 Recommended procedures 
5n3 Training 
5.4 Anticipated areas of change 
5.5 Transition planning 
6; Notes 
= he Appendixes 
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Scope. This section shall be divided into the following 
paragraphs: 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which this document 
applies, including, as applicable, identification number(s), 
title(s), abbreviation(s), version number(s), and release 
number(s) . 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
Maintenance; identify the project sponsor, user, developer, and 
Support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


Software development planning. This section shall be divided 
into the following paragraphs to describe the contractor’s plans 
for conducting the software development effort. 


Overview of the work to be done. This paragraph shall be divided 
into subparagraphs as needed to provide an overview of the work 
to be accomplished and to establish the context for the planning 
described in later sections. It shall include, as applicable, 
contractual and other requirements and constraints regarding: 


a. The system and software to be developed 

| 6 Ye The documentation required 

C3 Overview of the system life cycle and the position of the 
project within that life cycle 

ge The software life cycle model to be used 

e. Project schedules and resources 

ee Other aspects of the project, such as security, privacy, 


methods, standards to be followed, testing constraints, etc. 


Complying with 77-SDD-000102 general requirements. This 
paragraph shall be divided into subparagraphs as needed to 


provide the following information. Provisions corresponding to 
non-required activities may be satisfied by the words "Not 
applicable." Each subparagraph shall identify applicable 
risks/uncertainties and plans for dealing with them. 


a. The software development process to be used, including: 


14 A proposed life cycle model for the software if none is 
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established in the contract, that is, a set of phases, 
builds, increments, blocks, or other project stages, 
and the objectives of each. (Note: The remainder of 
this DID uses the term "build;" this term should be 
interpreted to suit the project) 


2) A mapping of the activities required by MIL-STD-SDD 
(and other contract provisions) onto that portion of 
the software life cycle model covered by the contract, 
Elavwts;) scent irication of ‘the activities to be 
performed in each build and, as applicable, their 
relationships to one another 


|e General plans for software engineering, including: 

1) The software development methods to be used, including 
the tools and procedures to be used in support of these 
methods 

2) The approach to be followed for identifying, 


evaluating, and incorporating reusable software, 
including identification of any candidate or selected 
reusable components known at the time this plan is 


prepared 
2) The approach to be followed for safety analysis 
4) The approach to be followed for analyzing, 


allocating, and monitoring the processing resource and 
reserve requirements established for the software 


by) The approach to be followed for recording the 
rationale for key decisions 


Ge General plans for software testing, including the approach 
to be followed for: 


De) Achieving the required level of independence 

2) Including testing on the target computer system or an 
equivalent system 

3) Stressing the software at the limits of its specified 
requirements 


Complying with 77-SDD-000102 detailed requirements. This 
paragraph shall be divided into the subparagraphs as needed to 


provide the following information. Provisions corresponding to 
non-required activities may be satisfied by the words "Not 
applicable." The discussion of each activity shall include the 
approach (methods/procedures/tools) to be applied to 1) the 
analysis or other technical tasks involved, 2) the recording of 
results, and 3) the preparation of associated deliverables, if 
applicable. The discussion shall also identify applicable 
risks/uncertainties and plans for dealing with them. 
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The approach to be followed for developing project plans in 
each build, including: 


1) Further development of this software development plan 

2) Planning CSCI and CSCI integration testing 

3) Performing or participating in planning system testing 

4) Planning for transition to software support 

5) Planning for software installation and training at user 
sites 


The approach to be followed for establishing, controlling, 
and maintaining a software development environment in each 
build, including descriptions of: 


aby) The software engineering environment 

2) The software test environment 

3) The software development library 

4) The software development files 

5) Design and coding standards to be used 

6) Non-deliverable software to be used 

7) Any other software standards and procedures to be used 


The approach to be followed for performing or participating 
in system requirements analysis in each build, including: 


1) Analyzing user input 
2) Defining the operational concept 
3) Defining the system requirements 


The approach to be followed for performing or participating 
in system design analysis in each build, including: 


is) Developing the system behavioral design 
Ny Developing the system architectural design 


The approach to be followed for software requirements 
analysis in each build, including: 


1) Defining the CSCI engineering (and corresponding 
qualification) requirements 
2) Defining the CSCI interface (and corresponding 


qualification) requirements 


The approach to be followed for performing software 
architectural design in each build, including: 


Ns) Developing the CSCI behavioral design 
2) Developing the CSCI architectural design 
2) Developing the database logical design 


The approach to be followed for performing software detailed 
design in each build, including: 


2) Developing the CSCI detailed design 
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2) Developing the CSCI interface design 
3) Developing the database physical design 


The approach to be followed for coding and unit testing in 
each build, including the programming language(s) to be 
used, including: 


a) Coding software units 

2) Populating those databases to be populated as part of 
software development 

) Preparing for unit testing 

) Performing unit testing 

) Revision and retesting based on test results 

) Recording unit test results 


The approach to be followed for unit integration and testing 
in each build, including: 


1) Preparing for unit integration and testing 
2) Performing unit integration and testing 

3) Revision and retesting based on test results 
4) Recording unit integration and test results 


The approach to be followed for CSCI testing in each build, 
including: 


1) Preparing CSCI test cases 

2) Preparing CSCI test procedures 

3) Dry run of CSCI test procedures 

4) Performing CSCI testing (including Government witnessed 
testing, as applicable) 

5) Revision and retesting based on test results 

6) Analyzing and recording CSCI test results 

7) Updating CSCI test cases and procedures 


The approach to be followed for CSCI integration and testing 
an cachhburid, ineluding: 


hy Preparing CSCI integration and test cases 

Zz) Preparing CSCI integration and test procedures 

a) Dry run of CSCI integration and test procedures 

4) Performing CSCI integration and testing (including 
Government witnessed testing, as applicable) 

5) Revision and retesting based on test results 

6) Analyzing and recording CSCI integration and test 
results 

a) Updating CSCI integration and test cases and procedures 


The approach to be followed for performing or participating 
in system testing in each build, including: 


15) Preparing system test cases 
2) Preparing system test procedures 
3) Dry run of system test procedures 
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4) Performing system testing (including Government 
witnessed testing, as applicable) 


5) Revision and retesting based on test results 
6) Analyzing and recording system test results 
7) Updating system test cases and procedures 


The approach to be followed for preparing for software use 
and support in each build, including: 


a) Developing software user manuals 

2) Developing computer center software operator manuals 

3) Developing software input/output manuals 

4) Developing computer system operator manuals 

5) Developing computer instruction set architecture 
manuals 

6) Developing firmware support manuals 

7) Performing installation and training at user sites 

8) Transitioning software and environments to the 


designated support site 


The approach to be followed for preparing for software 
delivery in each build, including: 


sh) Preparing executable code for delivery 

2) Preparing source code for delivery 

3) Developing software product specifications 
4) Developing version descriptions 

5 Supporting Functional Configuration Audit (s) 
6) Supporting Physical Configuration Audit (s) 


The approach to be followed for performing software product 
evaluations of contractor and subcontractor products in each 
build, including: 


1) Performing in-process software product evaluations 

2) Performing final software product evaluations 

3) Achieving the required independence in software product 
evaluation activities 

4) Preparing and maintaining software product evaluation 


records, including items to be recorded 


The approach to be followed for performing software 
configuration management in each build, including: 


1S Controlling development products, including: 
a) Configuration identification of development 
products 
b) Configuration control of development products 
2) Interface with Government Configuration Management, 
Including: 
a) Supporting the baselining of specifications 
b) Using Engineering Change Proposals 


co) Configuration status accounting, including the 
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format, content, and purpose of reports to be used 
3) Storage, handling, and delivery of project media 


The approach to be followed for performing corrective 
action and process improvement in each build, including: 


1) Preparing problem/change reports, including the items 
to be included 
2) Implementing a corrective action and process 


improvement system 


The approach to be followed for holding joint 
(customer/contractor) reviews in each build, including: 


a) A proposed set of technical-level reviews, including 
the items to be reviewed, objectives, and preparatory 
and follow-up activities for each review 


2) A proposed set of management-level reviews, including 
the items to be reviewed, objectives, and preparatory 
and follow-up activities for each review 


The approach to be followed for performing software 
development management in each build, including: 


i) Risk management 

2) Complying with the security and privacy requirements 
in the contract 

3) Managing subcontractors 

4) Interfacing with software IV&V agents 

5) Coordinating software development efforts to ensure 
compatibility at interfaces with associate contractors 

6) Applying management indicators, including indicators 


to be used, data to be collected, methods for 
interpreting/applying the data, and reporting 
mechanisms 


The approach to be followed for performing any other 
software development activities in each build 


Schedules. This paragraph shall present the schedule(s) for the 


project. It shall include: 


a. 


Schedule(s) identifying the activities in each build and 
showing initiation of each activity, availability of draft 
and final deliverables and other milestones, and completion 
of each activity 


An activity network, depicting sequential relationships and 
dependencies among activities and identifying those 
activities that impose the greatest time restrictions on the 
project 
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Project organization and resources. This paragraph shall be 
divided into subparagraphs as needed to describe: 


a. The organizational structure to be used on the project, 
including the organizations involved, their relationships to 
one another, and the authority and responsibility of each 
organization for carrying out required activities 


Dy The resources to be applied to the project, including: 
1) Personnel resources: 
a) Estimated staff-loading (number of personnel over 
time) 
b) Breakdown of the staff-loading numbers by 
responsibility 
Cc) Overview of the skill levels, geographic 


locations, and security clearances 


2) Overview of contractor facilities to be used 

3) Government furnished items facilities required and 
dates needed 

4) Other required resources, plan for obtaining them, and 


need/availability dates 


Software installation planning. This section shall be divided 
into the following paragraphs to describe the contractor’s plans 
for installing the software at user sites. 


Installation overview. This paragraph shall be divided into 
subparagraphs as needed to provide the following information: 


a. A general description of the installation process, including 
list of sites and installation schedule 


b. The organizational name, office symbol/code, and 
telephone number of a contact for questions relating to 
installation 

ok! A list of support materials required for the installation, 


including magnetic tapes, disk packs, computer printer 
paper, and special forms 


Oi, A description of the briefings, seminars, and training to be 
provided 
e. A list and brief description of each task required for the 


system installation, including responsible organization 


ES A description of the number and skill level of the personnel 
required during the installation period and the days and 
times they will be needed, including the need for multishift 
operation, clerical support, etc. 


2p An overview of security considerations associated with the system 
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Site information for computer operations personnel. This 
paragraph applies if the system will be installed in computer 


center(s) for users to access via terminals or using batch 
inputs/ outputs. If this type of installation does not apply, 
this paragraph shall contain the words "Not applicable." 


(Site Name). This paragraph shall identify a site or set of 
Sites and provide the following information for those sites. 


a. Schedule of activities to be accomplished during 
installation 
be Inventory of software required to support the installation, 


including name, identification code or acronym, security 
classification, and whether the software is expected to be 
on site or will be delivered for the installation 


oe Physical facilities and accommodations required during the 
installation period, including classroom, work space, 
training aids, hardware, transportation, and lodging, and 
the days and times they will be needed 


alk, Composition of the installation team, and each member’s 
tasks 

e. Step-by-step procedures for accomplishing the installation 
and conversion from the old system 

es Data update procedures during the installation period, if 


different from normal, including step-by-step procedures for 
updating the converted data 


Site information for user personnel. This section shall provide 
users with the information necessary to accomplish an orderly 


installation. If more than one type of user is involved, 
separate information shall be provided for each, as applicable. 


(Site Name). This paragraphs shall identify a site or set of 
sites and shall provide the following information for those 
sites: 


a. Schedule of activities to be accomplished by the user during 
installation 

be Step-by-step procedures for accomplishing the installation 
and conversion 

ox The user’s data update procedures during the installation 


period, if different from normal, including step-by-step 
procedures for updating the converted data 


Software support planning. This section shall be divided into 
the following paragraphs to describe the contractor’s plans for 
transitioning the software to the support agency. 


Software support resources. This paragraph shall be divided into 
subparagraphs as needed to identify and describe the components 
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of the software engineering and test environments required to 
Support the deliverable software (including modify, document, 
test, copy, distribute, and control). Items to be described 
shall include the following, as applicable: 


a. Facilities: buildings or building features required for 
Support; mock-ups; power requirements; security and safety 
measures 

D. Hardware: computer and other equipment required for support, 


including specific model numbers, acceptable alternatives, 
rationale for including, status of each item (Government - 
furnished, deliverable, already owned by support agency, 
must be acquired), information about where to acquire, known 
limitations, reference to user/operator manuals or 
instructions 


cc. Software: software and associated documentation require for 
Support, including titles, version numbers, acceptable 
alternatives, rationale for including, status of each item 
(Government-furnished, deliverable, already owned by support 
agency, must be acquired), information about where to 
acquire, known limitations, reference to user/operator 
manuals or instructions 


Ge Other documentation needed for support, including titles, 
numbers, versions; acceptable alternatives, rationale for 
including, status of each document (Government -furnished, 
deliverable, already owned by support agency, must be 
acquired), information about where to acquire, known 
limitations 


e. Personnel needed to support the deliverable software, 
including number of personnel, types and levels of skills 
and expertise, and security clearances. This paragraph 
shall cite, as applicable, actual staffing on the 
development project, as applicable to estimate how to staff 
the support effort 


i Other resources required for support, including consumable 
such as magnetic tapes, together with an estimate of the 
type and number that should be acquired 


ce The interrelationship of the components identified in the 
preceding paragraphs 


Recommended procedures. This paragraph shall be describe 
procedures that the contractor may wish to recommend to the 
support agency for supporting the deliverable software. Included 
may be procedures for software support management, software 
engineering, software testing, software product evaluations, 
software configuration management, or other activities. 
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Training. This paragraph shall describe the contractor’s plans 
for training personnel to manage and implement support of the 
deliverable software. The schedule and location for all required 
training shall be provided, as well as the delineation between 
classroom training and "hands-on" training. This paragraph shall 
provide (either directly or by reference) provisions for 
familiarization with the operational software and target 
computer(s), the support software and host system, and equipment 
maintenance procedures, as applicable. 


Anticipated areas of change. This paragraph shall describe the 
anticipated areas of change to the deliverable software. 


Transition planning. This paragraph shall be divided into 
subparagraphs as needed to describe the contractor’s plans for 
transitioning the deliverable software to the support agency. 
Included shall be descriptions of: 


an All activities to be performed to transition the deliverable 
software to support 

D. Roles and responsibilities for each activity 

Cc. The resources required and the source of each resource 

cls Schedules and milestones for transition activities 

e. Procedures for installation and checkout of the 


deliverable software in the support environment designated 
by the contracting agency 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary). This section shall include an 
alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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- DOCUMENT: BLM 80014B 
SOFTWARE TEST PLAN (STP) 


DOCUMENT : 


Purpose: 


CONTENTS : 


BLM 80014B 


SOFTWARE TEST PLAN (STP) 


The Software Test Plan (STP) describes plans for 
testing one or more Computer Software Configuration 
Items (CSCIs), integrated groups of CSCIs or 
CSCIs/HWCIs, and, possibly, a software system or 
segment. The STP identifies the software test 
environment resources required for the testing, 
describes the test approach, identifies the tests to be 
performed, and provides schedules for test activities. 


The STP enables the Government to assess the adequacy 
of planning for test activities. 


This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID may be used as an alternative to the 
Consolidated Software Test Document and the Completely 
Consolidated Software Development Record). Only one of 
these three DIDs should be applied to a given set of 
data. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." For data delivered in an alternative 
form, this representation need occur only in the table 
of contents or equivalent. 


DOCUMENT STRUCTURE: 


ae Scope 
1.1 Identification 
1.2 System overview 
1.3 Document overview 
1.4 Relationship to other plans 


Zu Referenced documents 
Bi Software test environment 
3.x (Name of test site(s) ) 
tie anal Software items 
exe? Hardware and firmware items 
3x .3 Other materials 
3.x.4 Proprietary nature, and Government 
rights 
3x25 Installation, testing, and control 
ge als Participating organizations 
Cheb ese | Personnel requirements 
lee qi Orientation plan 
Anko Tests to be performed 


4 


NO U1 


Test identification 
4.1 General 


Awl. Test levels 

4.1.2 Test 

40n 3 General test requirements 

4.1.4 Test Progression 

Al, . 5 Data recording, reduction, and 
analysis 
4.2 Planned tests 

4.2.x (Item(s) to be tested) 

AL2RKAY. (Test name and project- 


unique identifier) 
Test schedules 
Notes 
Appendixes 
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Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Relationship to other plans. This paragraph shall 
describe the relationship, if any, of the STP to 


related project management plans. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this plan. This section shall also identify the source 
for all documents not available through normal 
Government stocking activities. 


Software test environment. This section shall be 
divided into the following paragraphs to describe the 
software test environment at each intended test site. 
To reduce duplication, references may be made in the 
paragraphs below to the software engineering 
environment described in the Software Development Plan 
(SDP) for those resources that are used in both 
environments. 


(Name of test site(s)). This paragraph shall identify 
one or more test sites to be used for the testing, and 
shall be divided into the following subparagraphs to 
describe the software test environment at the site(s). 
If all tests will be conducted at a single site, this 
paragraph and its subparagraphs shall be presented only 
once. If multiple test sites use the same or similar 
software test environments, they may be discussed 
together. Duplicative information among test site 
descriptions may be reduced by referencing earlier 
descriptions. 


Software items. This paragraph shall identify by name, 
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number, 
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and version, aS applicable, the software items (e.g., 
operating systems, compilers, communications software, 
related applications software, databases, input files, 
code auditors, dynamic path analyzers, test drivers, 
preprocessors, test data generators, test control 
software, other special test software, 
post**processors) necessary to perform the planned 


testing activities at the test site(s). This paragraph 
shall describe the purpose of each item, describe their 
media (tape, disk, etc.), identify those that are 


expected to be supplied by the site, and identify any 
classified processing or other security or privacy 
issues associated with the software items. 


Hardware and firmware items. This paragraph shall 


identify by 


sx. 3 


name, number, and version, as applicable, the computer 
hardware, interfacing equipment, communications 
equipment, test data reduction equipment, apparatus 
such as extra peripherals (tape drives, printers, 
plotters), test message generators, test timing 
devices, test event records, etc., and firmware items 
that will be used in the software test environment at 
the test site(s). This paragraph shall describe the 
purpose of each item, state the period of usage and the 
quantity required of each item, identify those that are 
expected to be supplied by the site, and identify any 
classified processing or other security or privacy 
issues associated with the items. 


Other materials. This paragraph shall identify and 


describe any 


ek. & 
paragraph 
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other materials needed for the testing at the test 
site(s). These materials may include manuals, listings 
of software and data, media containing the software to 
be tested, media containing data to be used in the 
tests, sample listings of outputs, such as test 
worksheets and other forms or instructions, etc. This 
paragraph shall identify those items that are to be 
delivered to the site and those that are expected to be 
Supplied by the site. The description shall include 
the type, layout, and quantity of the materials, as 
applicable. This paragraph shall identify any 
classified processing or other security or privacy 
issues associated with the items. 


Proprietary nature, and Government rights. This 
shall 


identify the proprietary nature and Government rights 
associated with each item of the software test 
environment. 


Installation, testing, and control. This paragraph 
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shall 
identify the contractor’s plans for performing each of 
the following, possibly in conjunction with personnel 
at the test site(s): 


a. Installing and testing each item of the software 
Leet 
environment prior to its use. 
be Controlling and maintaining each item of the 
software test 
environment 
Bk, 6 Participating organizations. This paragraph shall 


identify the 
organizations that will participate in the testing at 
the test sites(s). 


Seo. / Personnel requirements. This paragraph shall identify 

the number 
of personnel with indicated skill types required during 
the test period at the test site(s) and the dates and 
times they will be needed. It will indicate special 
requirements, such as multishift operation and 
assignment or retention of key skills to ensure 
continuity and consistency in extensive test programs. 


3.x. 8 Orientation plan. This paragraph shall describe any 

orientation 
and training to be given before and during the testing. 
This information shall be related to the personnel 
requirements in paragraph 3.x.7. This training may 
include user instruction, operator instruction, 
Maintenance and control group instruction, and 
orientation briefings to staff personnel. If extensive 
training is anticipated, a separate plan may be 
developed and referenced here. 


2.%.9 Tests to be performed. This paragraph shall identify, 


referencing section 4, the tests to be performed at the 
test site(s). 


4. Test identification. This section shall be divided 
into the following paragraphs to identify and describe 
each test to which this STP applies. 


4.1 General information. This paragraph shall be divided 
into subparagraphs to present general information 
applicable to the overall testing to be performed. 


ee oe Test levels. This paragraph shall describe the levels 
at which 
testing will be performed. For example: CSCI level, 
CSCI to CSCI integration level, CSCI to HWCI 
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integration level, system level. 
Test classes. This paragraph shall describe the types 


of tests that will be performed (e.g., stress tests, 
timing-tests, erroneous input tests, maximum capacity 
tests). 


General test requirements. This subparagraph shall 


requirements that apply to all of the tests or toa 
group of tests. For example: "Each test shall include 
nominal, maximum, and minimum values;" "Each test of 
type x shall use live data;" "Execution size and time 
shall be measured for each CSCI." Included shall be a 
Statement of the extent of testing to be performed for 
all, or for groups of, tests and rationale for the 
extent selected. The extent of testing shall be 
expressed as a percentage of some well defined total 
quantity, as the number of samples of discrete 
operating conditions or values, or other sampling 
approach. 


Test Progression. In cases of progressive or 


cumulative tests, 


al. 5 
paragraph 
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this paragraph shall explain the planned sequence or 
progression of tests. 


Data recording, reduction, and analysis. This 
shall 


identify and describe the data recording, reduction, 
and analysis procedures to be used during and after the 
tests identified in this STP. These procedures shall 
include, as applicable, manual, automatic, and semi- 
automatic techniques for recording test results, 
manipulating the raw results into a form suitable for 
evaluation, and retaining the results of data reduction 
and analysis. 


Planned tests. This paragraph shall be divided into 
the following subparagraphs to describe the total scope 
of the planned testing. 


(Item(s) to be tested). This paragraph shall identify 


group of CSCIs, subsystem, system, or other entity by 
name and project-unique identifier, and shall be 
divided into the following sub-paragraphs to describe 
the testing planned for the item(s). (Note: the 
"tests" in this plan are collections of test cases. 
There is no intent to describe each test case in this 
document. ) 


(Test name and project-unique identifier). This 
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subparagraph 


shall identify a test by name and project-unique 
identifier and shall provide the information specified 
below for the test. Some or all of this information 
may be provided graphically. Reference may be made as 
needed .to the general information in 4.1. 


as Test objective 
ley Test level 
Gc. Test type or class 
ae Qualification method(s) as specified in the 
requirements 
specification 
e. Cross reference to the software or system 
requirements 
addressed by this test 
ie Any special requirements [e.g., 48 hours of 
continuous 
facility time, weapon simulation, extent of test, 
use of a special input or database, etc.] 
2 Type of data to be recorded 
lsh: Type of data recording/reduction/analysis to be 
employed 
i? Assumptions and constraints, such as anticipated 
limitations 
on the test due to system or test conditions-- 
timing, interfaces, equipment, personnel, 
database, etc.) 
eis Any security and privacy considerations associated 
with the 


test due to system or test conditions 


Test schedules. This section shall contain or 
reference the schedules for conducting the tests 
identified in this plan. It shall provide: 


a. A listing or chart depicting the sites at 
which the 
testing will be scheduled and the time frames 
during which the testing will be conducted 


De A chart for each test site depicting the 
activities and 
events listed below, as applicable, in 
chronological order with supporting narrative 
as necessary: 


1) Overall on-site test period by calendar 
date and 
portions of the period assigned to major 
portions of test 


zo) Pretest on-site period required for 


system 


database/ 


debugging, orientation, and 
familiarization 


3) Period assigned for the collection of 
data bank values, input 
values, and other operational 
data required for system test 


4) Period assigned for user orientation and 
familiarization with system 
documentation 


ey Period assigned for user training, 


operator 


and 


training, maintenance and control group 
training, and management orientation 
briefing 


6) Period assigned for preparation, review, 
approval of the Software Test Report 


Notes. This section shall contain any general 
information that aids in understanding this document. 
This section shall include an alphabetical listing of 
all acronyms, abbreviations, and their meanings as used 
in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. Appendixes may be bound as 
separate documents for ease in handling. Appendixes 
shall be lettered alphabetically (A, B, etc.). 
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DOCUMENT : 


PURPOSE: 


CONTENT : 


BLM 80015B 


SOFTWARE TEST DESCRIPTION (STD) 


The Software Test Description (STD) contains the test 
cases and test procedures necessary to perform testing 
of a Computer Software Configuration Item (CSCI), an 
integrated group of CSCIs or CSCIs/HWCIs, or a software 
system or segment. 


The STD enables the Government to assess the adequacy 
of the test cases and test procedures to be performed. 


This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
Test Document and Completely Consolidated Software 
Development Record. Only one of these three DIDs 
should be applied to a given set of data. 

Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." For data delivered in an alternative 
form, this representation need occur only in the table 
of contents or equivalent. 


DOCUMENT STRUCTURE: 


ane Scope 
ieierdentification 
1.2 System overview 
1.3 Document overview 


Pa Referenced documents 
3% Test preparations 
3.x (Test name and project-unique identifier) 
saxml (Test name) schedule 
S2x%.2 (Test name) pre-test procedures 


Soho aap sal Hardware preparation 
atx 3 2 Software and data 


preparation 
CfMD ASP ARG, Other pre-test 
preparations 
4. Test descriptions 
4.x (Test name and project-Unique identifier) 

4.xX.y (Test case name and project-unique 

identifier) 
Aux.yis Requirements traceability 
An KeyY .2 Means of control 
4.xey.3 Initialization 
4.x.y.4 Test inputs 
Awmxavy sd Expected test results 
4-X5V00 Criteria for evaluating 


Se, aaa & 
updates 


Cheaey, qa 


results 
4.x.y.7 Test procedure 
4.x.y.8 Assumptions and 
constraints 

5 Notes 

6. Appendixes 


Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this document. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


Test preparations. This section shall be divided into 
the following paragraphs to describe test preparations. 
Security and privacy considerations shall be included 
as applicable. 


(Test name and project-unique identifier). This 


paragraph shall identify a test by name and identifier, 
shall provide a brief description, and shall be divided 
into the following subparagraphs. 


(Test name) schedule. This paragraph shall provide any 


or refinements to the test schedules and locations in 
the Software Test Plan. These updates shall include, 
as applicable, briefings, pre-test activities, testing, 
debriefings, and data reduction and analysis. 


(Test name) pre-test procedures. This paragraph shall 


be divided 


into the following subparagraphs to describe the 
preparation and setup for the test. When the 
information required duplicates information previously 
specified for another test, that information may be 
referenced rather than repeated. 


ep areal Hardware preparation. This paragraph shall describe 


procedures necessary to prepare the hardware for the 
test. Reference may be made to published operating 
manuals for these procedures. The following shall be 
provided, as applicable: 


a. The specific hardware to be used, identified by 
name and, if 
applicable, number. 


be Any switch settings and cabling necessary to 
connect the 

hardware. 
ete One or more diagrams to show hardware, 
interconnecting 

control, and data paths. 
dg Precise step-by-step instructions for placing the 

hardware 


in a state of readiness. 


ee 2 Software and data preparation. This paragraph shall 
describe the 
procedures and related information necessary to prepare 
the item(s) under test and any required support 
software and data for the test. Reference may be made 
to published software manuals for these procedures. 
The following information shall be provided, as 
applicable: 


a. The storage medium of the item(s) under test 
(e.g., magnetic 
tape, diskette). 


bt The storage medium of any support software (e.g., 
Simulators, test drivers). 
ox The storage medium of any stored data needed for 
the test. 
ay Instructions for loading the software and data, 
including 
required sequence. 
e. Instructions for software and data initialization 


common to 
more than one test case. 


A ee ea) Other pre-test preparations. This paragraph shall 
describe any other pre-test personnel actions, preparations, or 


procedures necessary to perform the test. 


A Test descriptions. This section shall be divided into 
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the following paragraphs. Security and privacy 
considerations shall be included as applicable. 


asx (Test name and project-unique identifier). This 


paragraph shall identify a test by name and project- 
unique identifier and shall be divided into the 
following subparagraphs. 


4.X.Y (Test case name and project-unique identifier). This 
paragraph 
shall identify a test case by name and project-unique 
identifier, state its purpose, and provide a brief 
description. The following subparagraphs shall provide 
a detailed description of the test case. 


ax. y. 1 Requirements traceability. This paragraph shall 
identify the 
software requirements that are addressed by the test 
case. 


2 Ae ae aa Means of control. This paragraph shall indicate 
whether the test 
case is to be controlled by: 


a. Manual means - manual insertion of inputs and 
manual control 
of test sequence. 
bs Semiautomatic means - manual insertion of inputs; 
automatic 
control of test sequence (by test software). 
(ey Automatic means - preparation and use of test 
software to 
provide input, conduct test, and monitor and 
record test results. 
4.x.y.3 Initialization. This paragraph shall identify any 
prerequisite 
conditions that must be established prior to performing 
the test case. When the information required in this 
subparagraph duplicates information previously 
specified, that information may be referenced rather 
than repeated. The following considerations shall be 
discussed, as applicable: 


a. Hardware and software configuration 
be Flags, initial breakpoints, pointers, control 
parameters, or 
initial data to be set/reset prior to test 
commencement 
as Preset hardware conditions or electrical states 
necessary to 
run the test case 
d. Initial conditions to be used in making timing 
measurements e. Conditioning of the simulated 
environment 
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Bey Special instructions peculiar to the test case 


4.x.y<c4 Test inputs. This paragraph shall describe the test 
inputs 
necessary for the test case. The following shall be 
provided, as applicable: 
a. Name, purpose, and description (e.g., range of 
values, 
accuracy) of each test input. 
b: Source of the test input and the method to be used 
ie} 
selecting the test input. 
eh Whether the test input is real or simulated. 
ae Time or event sequence of test input (e.g., in 


response to 
question Y, input 4.375). 
e. The manner in which the input data will be 


controlled to: 


1) Test the item(s) with a minimum/reasonable 
number of 
data types and values. 
Za) Exercise the item(s) with a range of valid 
data types 
and values that test for overload, 
saturation, and other "worst case" effects. 
3) Exercise the item(s) with invalid data types 


and values 


“WS a ine 
all 


4.x.y.6 
identify 


be 


input 


to test for appropriate handling of irregular 
inputs. 


Expected test results. This paragraph shall identify 


expected test results for the test case. Both 
intermediate and final test results shall be provided, 
as applicable. 


Criteria for evaluating results. This paragraph shall 


the criteria to be used for evaluating the intermediate 
and final results of the test case. When the 
information required in this paragraph duplicates 
information previously specified, that information may 
be referenced in this paragraph. For each test result, 
the following information shall be provided, as 
applicable: 


as The range over which an output can vary and still 
acceptable. 
oe Minimum number of combinations or alternatives of 
and 


output conditions that constitute an acceptable 


test result. 
cc Maximum/minimum allowable test duration, in terms 


of time or 


number of events. 
d. Maximum number of interrupts, halts, or other 


system breaks 


that may occur 


e. Allowable severity of processing errors. 
t% Conditions under which the result is inconclusive 
and re- 


testing is to be performed. 
Conditions under which the outputs are to be 


interpreted as 


indicating irregularities in input test data, in 
the test database/data bank, or in test 
procedures. 

ne Allowable indications of the control, status, and 


results of 


Bex. y 7 
procedure 


the test and the readiness for the next test case 
(may be output of auxiliary test software). 
1 Additional criteria not mentioned above. 


Test procedure. This paragraph shall define the test 


for the test case. The test procedure shall be defined 
as a series of individually numbered steps listed 
sequentially in the order in which the steps are to be 
performed. For convenience in document maintenance, 
the test procedures may be included as an appendix and 
referenced in this paragraph. The appropriate level of 
detail in each test procedure depends on the type of 
software being tested. For some software, each 
keystroke may be a separate test procedure step; for 
most software, each step may include a logically 
related series of keystrokes or other actions. The 
appropriate level of detail is the level at which it is 
useful to specify expected results and compare them to 
actual results. The following shall be provided for 
each test procedure, as applicable: 


a. Test operator actions and equipment operation 


required for 


each step, including commands, as applicable, to: 


at) Initiate the test case 

oy Inspect test conditions 

of Perform interim evaluations of test results 

4) Record data 

5) Halt or interrupt the test case 

6) Request data dumps or other aids, if needed 
74) Modify the database/data bank 

8) Repeat the test case if unsuccessful 


9) Apply alternate modes as required by the test 
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10) Terminate the test case 


bs Expected result for each step 
om Evaluation criteria for each step, as applicable 
ay. Actions to follow in the event of a program stop 


indicated error, such as: 


1) Recording of critical data from indicators 
for 

reference purposes. 
2) Halting or pausing time-sensitive test- 


support software 


test 


of test 
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and test apparatus. 


3) Collection of system and operator records of 
results. 
e. Procedures to be used to reduce and analyze test 


results to 
accomplish the following, as applicable: 


a) Detect whether an output has been produced. 
2) Identify media and location of data 
produced by the 
test case. 
3) Evaluate output as a basis for continuation 


sequence. 
4) Evaluate test output against required output. 


Assumptions and constraints. This paragraph shall 


identify any 


assumptions made and constraints or limitations imposed 
in the description of the test case due to system or 
test conditions, such as limitations on timing, 
interfaces, equipment, personnel, and database/data 
bank. If waivers or exceptions to specified limits and 
parameters are approved, they shall be identified and 
this paragraph shall address their effects and impacts 
upon the test case. 


Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of any terms and definitions needed 
to understand this document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 


La 


Img atia Seti ST {of a 


ft. ,tosTe basadifal 
; 4 cry oo (ft 
z cits 
eo } 
ie te6ias 
me .* ‘eo 
i 4 ba 
St EWIICEe 
> ‘1 —_ ' 
‘ 
re 
2 
* a3 i se fi 
cy; 1 
iJ 
' rac 
' 
? a ‘ 
i F LZ, 
c ¢ 7 S 
; na eee 2) 
yas 
‘ i & Z rey BS 
. 5h 25 al 
brs asd 
7 3a 7CE 
Lond 
iJ ' - ‘de j 1 AT 
' f ac act 
wid 3OGy 
: 2 ‘ 2 s byl - ae 
ee sly fo taperetel 
Fy > al a wa ) 2-8. 
. af ; <4 antes : ee 5s: 
1! s 
‘wee GLi y 


- ja 
ste (ose te? sivacx eeTosqea 
¥ 


_ 
7 of 

: 7 
i } 

a 


se 209 AkesSiuo aolssuisva | s& 
¢ oe 4 


iS te wale ad’ rip l IGA <6 


document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 


have been provided. 


DOCUMENT:BLM C-80025B 


CONSOLIDATED SOFTWARE 
REQUIREMENTS DOCUMENT (C-SRD) 


Alternate For: 


Operational Concepts - BLM 80035B 
System/Segment Specifications - BLM 80008B 
Software Requirements Specifications - BLM 80025B 


Interface Requirements Specifications - BLM 80026B 


DOCUMENT : 


PURPOSE: 


CONTENTS : 


BUM, C-80025B 


CONSOLIDATED SOFTWARE REQUIREMENTS DOCUMENT (C-SRD) 


The Consolidated Software Requirements Document (C-SRD) is a 
Single document encompassing the operational concept for a 
system and the requirements for the system, for one or more 
CSCIs, and for the external interfaces of those CSCIs. 


This document contains, in summary form, the contents of the 
Operational Concept Document (OCD), System/Segment 
Specification (SSS), Software Requirements Specifications 
(SRSs), and Interface Requirements Specifications (IRSs) for 
a project. 


A C-SRD is written as an alternative to the individual 
Software Requirements Specifications document. It is best 
Suited to a project on which a single concept and 
requirements document is most effective. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title in 
the document, followed by "This paragraph has been tailored 
Out 


DOCUMENT STRUCTURE: 


1 Scope 
1.1 Identification 
1.2 System overview 
1.3 Document overview 


PAR Referenced documents 
ae: Operational concept 
3.1 Current system or situation 
3.2 Justification for and nature of changes 
3.3 Concept for a new or modified system 
3.4 Operational scenarios 
3.5 Summary of impacts 
3.6 Analysis of the proposed system 
4. System/segment specification 
4.1 Requirements 


4.1.1 Definition 
4.1.2 Characteristics 


4.1.2.1 Performance characteristics 
4.1.2.2 Database/data bank requirements 
4.1.2.3 External interface requirements 
4.1.2.4 Physical 

4.1.2.5 System quality factors 

4.1.2.6 Environmental requirements 

Atl, 2.7 TransportabiLlity 

4.1.2.8 Flexibility and expansion 
AM Oe Portability 
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Logistics 
Personnel and training 
Characteristics of subordinate elements 
Precedence 
4.2 Quality assurance provisions 
4.3 Preparation for delivery 
Software requirements specification 
5.x becomes the Allocated Baseline for the 
corresponding CSCI. 
5.x (CSCI name/identifier) 
5.x.1 Engineering requirements 
5.x.1.1 CSCI external interface 
requirements 
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5.x.1.2 CSCI capability requirements 
5.x.1.3 CSCI internal interfaces 
5.x.1.4 CSCI internal data element 


requirements 
Adaptation requirements 
Sizing and timing requirements 
Safety requirements 
Security and privacy requirements 
Design constraints 

0 Software quality factors 

1 Human performance/human 
engineering requirements 

5.X.1.12 Requirements traceability 
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5.x.2 Qualification requirements 
5.x.3 Preparation for delivery 
Interface requirements specification 
6.1 Interface requirements 
6.1.1 Interface identification and diagrams 
6.1.x (Interface name and project-unique 
identifier) 
6.1.x.1 Data element requirements 
6.1.x.2 Messages or other data assemblies 
6.1.x.3 Interface priorities 
6.1.x.4 Interface/communication protocols 
Notes 
Appendixes 
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Scope. This section shall be divided into the following 
paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which this document 
applies, including, as applicable, identification number(s), 
title(s), abbreviation(s), version number(s), and release 
number(s). 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
maintenance; identify the project sponsor, user, developer, and 
support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


Operational concept. This section shall be divided into the 
following paragraphs to describe a proposed system in terms of 
the user needs it will fulfill, its relationship to existing 
systems or procedures, and the ways it will be used. 


Current system or situation. This paragraph shall be divided 
into subparagraphs as needed to describe: 


a. The background, objectives, and scope of the current system 
or situation. 


Db: Any operational policies and constraints that apply to the 
current system or situation. 


(ane The current system or situation, including variations in 
different states and modes of operation (e.g., regular, 
Maintenance, training, degraded, emergency, wartime) : 


1) The operational environment and its characteristic 

Z) Major components and the interconnections among these 
components 

3) Interfaces to external systems or procedures 

4) Capabilities/functions of the current system 

5) Chart and description of inputs, outputs, data flow, 
and manual/automated processes 

6) Performance characteristics, such as speed, throughput, 
volume, frequency 

7) Quality attributes, such as reliability, 


Maintainability, availability 
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8) Provisions for safety, security, privacy, and 
continuity of operations 


d. The types of users of the system, or personnel involved in 
the current situation, including, as applicable, 
organizational structures, training/skills, 
responsibilities, and interactions with one another. 


e. The support concept and environment for the current system 


Justification for and nature of changes. This paragraph shall be 
divided into subparagraphs as needed to describe: 


a. The justification for change, including: 
1) New or modified aspects of user needs, missions, 


objectives, environments, interfaces, personnel or 
other factors that require a new or modified system. 


2) Deficiencies or limitations in the current system or 
Situation that make it unable to respond to these 
factors. 

be New or modified capabilities or other changes needed to 


respond to these factors 
CG. Priorities among the changes 
rely Changes considered but not included 
e Assumptions and constraints applicable to the changes 


Concept for a new or modified system. This paragraph shall be 
divided into subparagraphs as needed to describe a new or 
modified system. It shall describe, as applicable: 


a. The background, objectives, and scope of the new or modified 
system 
be Any operational policies and constraints that apply to the 


new or modified system 


ce The new or modified system, including variations in 
different states and modes of operation (e.g., regular, 
maintenance, training, degraded, emergency, wartime) : 


1) The operational environment and its characteristics 

2) Major components and the interconnections among these 
components 

3) Interfaces to external systems or procedures 

4) Capabilities/functions of the new or modified system 

5) Chart and description of inputs, outputs, data flow, 
and manual/automated processes 

6) Performance characteristics, such as speed, throughput, 
volume, frequency 

7) Quality attributes, such as reliability, maintain- 


ability, availability 
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8) Provisions for safety, security, privacy, and 
continuity of operations 


ay The types of users of the system, including, as applicable, 
organizational structures, training/skills, 
responsibilities, and interactions with one another 


e. The support concept and environment for the new or modified 
system 


Operational scenarios. This paragraph shall describe one or more 
operational scenarios that illustrate the role of the new or 
modified system, its interface to other systems, and all states 
or modes identified for the system. 


Summary of impacts. This paragraph shall be divided into sub- 
paragraphs as needed to describe the operational and organization 
impacts on the user, development, and support/maintenance 
agency(ies), and the anticipated impacts on these organizations 
during the development process. 


Analysis of the proposed system. This paragraph shall be divided 
into subparagraphs as needed to provide: 


a. A qualitative and quantitative summary of the benefits to be 
obtained from the new or modified system, including new and 
enhanced capabilities or performance. 


be A qualitative and quantitative summary of disadvantages or 
limitations of the new or modified system. 


Gx A description of major alternatives considered, the trade- 
offs among them, and rationale for the decisions reached 


System/segment specification. This section shall be divided into 


the following paragraphs to specify the requirements (conditions 
for acceptance) for the system or segment. Upon Government 
approval this section becomes the Functional Baseline for the 
System or segment. The word "system" may be interpreted to mean 
"Segment" as applicable in this section. 


Requirements. 


Definition. This paragraph shall provide a brief description of 
the system, identifying any states or modes in which the system 
is required to operate (for example, idle, ready, active, post- 
use analysis, training, degraded, emergency, backup). Note: the 
distinction between states and modes is arbitrary. A system may 
be described in terms of states only, modes only, states within 
modes, modes within states, or any other scheme that seems 
useful. If the system operates without states or modes, this 
paragraph shall so state, without the need to create artificial 
distinctions. 
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4.1.2.4 


Characteristics. This paragraph shall be divided into the 
following subparagraphs to describe the requirements for the 
system. Each requirement or group of requirements shall be 
annotated to indicate the states and modes in which it applies, 
either in the text, in an accompanying table, or by other means. 


Performance characteristics. This paragraph shall be divided 
into subparagraphs, each identifying a capability of the system 
by name and project-unique identifier, describing its purpose, 
and itemizing the requirements for that capability. A 
"Capability" is defined as a group of related requirements. The 
word "capability" may be replaced by "function," "subject," 
"object," or other term useful for presenting the requirements 
Each requirement shall be given a unique identifier. The 
requirements shall include applicable parameters, such as 
response times, sequencing, accuracy, capacities (how much/how 
many), priorities, continuous operation requirements, and 
allowable deviations based on operating conditions, and shall 
express these parameters in measurable terms. The requirements 
shall also include required behavior under unexpected or "out of 
bounds" conditions and for maintaining continuity of operations 
in the event of emergencies. 


Database/data bank requirements. This paragraph shall be divided 


into subparagraphs as needed to identify each required database 
or data bank, state its purpose, and itemize the requirements 
imposed on it, including, as applicable, required data elements, 
required characteristics of the data elements, required relation- 
ships among data elements, and required storage capacity for the 
data, including growth capability. 


External interface requirements. This paragraph shall be divided 
into subparagraphs as needed to identify each external item with 


which the system is required to interface, state the purpose of 
the interface, describe the relationship between the interface 
and the states and modes of the system, and itemize the require- 
ments imposed on the system as a result of the interface, includ- 
ing, as applicable, physical interface requirements (dimensions, 
tolerances, loads, etc.); communication/data transfer require- 
ments; characteristics of the inputs that must be accepted by the 
system from the item; characteristics of the outputs that must be 
provided by the system to the item; security or privacy require- 
ments. 


Physical characteristics. This paragraph shall specify any 
requirements for physical characteristics (e.g., weight limits, 


dimensional limits, color, protective coatings) of the system. 
Considerations for determining physical requirements include 
transportation and storage, security, privacy, durability 
(freedom from corrosion, abrasion, or other damage), safety, 
vulnerability. If there are no physical requirements (such as 
for a software-only system), this paragraph may be satisfied by 
"Not Applicable." 
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4.1.4 


System quality factors. This paragraph shall be divided into 
subparagraphs as needed to specify any requirements pertaining to 
system quality factors, including, as applicable: 


a. Reliability (including failure contingencies) 
D Maintainability 

(ore Availability 

di 


Other quality factors 


Environmental requirements. This paragraph shall be divided into 
subparagraphs as needed to specify any requirements regarding the 
environment within which the system is required to operate, 
including, as applicable: 


a. Environmental conditions the system must withstand 

De Computer equipment that must be used by, or incorporated 
into the system. 

ez Support software that must be used by, or incorporated into, 
the system. . 

ols The communications environment within which the system must 
operate. 


Transportability. This paragraph shall specify any special 
requirements for transportation and materials handling. 


Flexibility and expansion. This paragraph shall specify any 
areas of growth that require planning for system flexibility and 


expansion and any system elements that require spare capacity to 
support flexibility and expansion. 


Portability. This paragraph shall specify any requirements for 
portability to permit employment, deployment, and logistic 
Support. 


Design and construction. This paragraph shall be divided into 
subparagraphs as needed to specify any minimum system design and 
construction standards for the system, including, as applicable, 
requirements for: 


Materials 

Nameplates and product marking 
Workmanship 

Interchangeability 

Safety 

Human engineering 

System security and privacy, 

Usage of Government furnished property 
Computer resource reserve capacity 


PTQmoaansdws 


Documentation. This paragraph shall any specify requirements for 
system documentation such as specifications, drawings, technical 

Manuals, test plans and procedures, and installation instruction 

data. 


bebivib: s¢ (603 Nioeitpeted etait 
‘ eioomortgpes.yne vi tvege oO 
-elcestiqgs Bn eaibniool 


ccepartines etvitel gearbufogs) ee aM a 
yiilidenisjoremM d 

> y3tildstisva Pe | 

siouos? vilfeugp zeiso.. +f 


; bit joomeag spe i pinempes bent 
toaq i babeot as siqssostegags 
ye aod? doidw oldstiv gosmmes hae 

-e{deasliqgas as ,erthulome 
i 75> (Ssx7nemtos tyra .s 
je23 toeme’s ‘4 eagmMOD a 
deve eld opm 
jon 236g -2 
Te ‘89. ang 
fonnmmoS> St: 2 
ajayveqo 
LS Orage 
i = a | Ps = 
VIPCES O80 Vito se 
ney Iaft dteore 3 srr18 
¢ r eer. a Pa 1f20x8 
. x L4 a Aa, 5% 
5 ’ TT ‘ o* >| 
’ Lf ) ” ’ Pes ¢ 7 IQ 


s slis tem 

et ac) te loan rl . 

iirfansmtaoe 

VS LTLEG er aAnlo yeacot 
vIe The 

tah. ws RAD 

: VSt70>0e mst re 

i So Snszevou ea Spay 

MaCy6 IvVISASs. saTsoest TEIN 


® 


Phe wn oO Oe 


> 


oss vwisosca. viz i453 Agetpgaseq. aig ae 
us cey BP, Olrge5is “ge 38 dove 2676 tremusob MeIaYe 


>I y Tre mr 54 Ba Tuos nepsec hes cosig 3367 leas 


<i. 5 


4.2 


Logistics. This paragraph shall specify any logistic consider- 
ations and conditions that apply to the operational requirements. 
These considerations and conditions may include maintenance, 
transportation modes, supply system requirements, impact on 
existing facilities, and impact on existing equipment, 


Personnel and training. This paragraph shall be divided into 
sub-paragraphs as needed to specify: 


a. Personnel requirements that must be integrated into system 
design 
b. Requirements for the training to be provided: 


responsibilities; required equipment; training devices to be 
developed; training times and locations; training materials 


Characteristics of subordinate elements. This paragraph shall be 
divided into subparagraphs as needed to identify and describe 
each segment of the system. This paragraph shall describe the 
relation-ships between the segments. . 


Precedence. This paragraph shall specify any order of precedence 
or assigned weights indicating the relative importance of the 
requirements. 


Quality assurance provisions. This paragraph shall be divided 


into subparagraphs as needed to specify how compliance with the 
requirements of sections 4.1 and 4.3 is to be assured. It shall 
include: 


a. Definition of the qualification methods to be used (for 
example, demonstration, test, analysis, 
inspection) 

Dy Assignment of one or more of these methods to each 

requirement. 

e Description of any special tests or examinations to be 


performed, including requirements, as applicable, for 
standard samples, preproduction or periodic production 
samples, a pilot model, or a pilot lot. 


Preparation for delivery. This paragraph shall specify 
requirements for the preparation of the system and all its 


components for delivery, including packaging and handling. 


Software requirements specification. This section shall be 
divided into the following paragraphs to specify the engineering 


and qualification requirements for one or more Computer Software 
Configuration Item (CSCIs). Upon Government approval and 
authentication, each section 5.x becomes the Allocated Baseline 
for the corresponding CSCI. 


(CSCI name/identifier). 
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Engineering requirements. This paragraph shall be divided into 
the following subparagraphs to specify the engineering 
requirements (conditions for acceptance) for the CSCI. If the 
CSCI is part of a larger system, requirements to be included 
shall be the software requirements generated to satisfy the 
system or segment requirements allocated to this CSCI. 


CSCI_ external interface requirements. This paragraph shall 
identify each required CSCI-external interface and shall 


reference Section 6 or other document for the requirements for 
each interface. 


CSCI capability requirements. This paragraph shall be divided 
into subparagraphs to identify each CSCI capability, state its 
purpose, and itemize the requirements associated with the 
Capability. Capabilities may be divided into subcapabilities as 
needed, and the word "capability" may be replaced with 
"function," "Subject," "object," or other term useful for 
presenting the requirements. The requirements shall include 
applicable parameters, such as response times, sequencing, 
accuracy, capacities (how much/how many), priorities, continuous 
operation requirements, and allowable deviations based on 
operating conditions, and shall express these parameters in 
measurable terms. The requirements shall also include required 
behavior under unexpected or "out of bounds" conditions and any 
provisions to be incorporated into the CSCI to provide continuity 
of operations in the event of emergencies. Each requirement shall 
be stated in such a way that an objective test can be defined for 
it. If the system of which the CSCI is a part can exist in 
various system states and modes, each CSCI requirement or group 
of requirements shall be correlated to those states and modes. 


CSCI internal interfaces. This paragraph shall identify any 
requirements imposed on the interfaces between the capabilities 
identified above. If all internal interfaces are left to the 
design, this fact shall be so stated. Each internal interface on 
which requirements are imposed shall be identified by name and 
project-unique identifier and the interface requirements shall be 
itemized. Internal interface diagrams depicting data flow, 
control flow, and other relevant information may be used to aid 
in this description. 


CSCI internal data element requirements. This paragraph shall 
specify any requirements imposed on the data elements internal to 


the CSCI. If all decisions about internal data elements are left 
to the design, this fact shall be so stated. If they have been 
covered elsewhere in this specification, they need not be 
repeated here. If requirements are imposed on data elements 
internal to the CSCI they shall include, as applicable: 


a. A project-unique identifier for the data element 

be A brief description of the data element 

c Units of measure required for the data element, such as 
seconds, meters, kilohertz 
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ae Limit/range of values required for the data element (for 
constants, the actual value) 


e. Accuracy required for the data element 

Ge Precision or resolution required for the data element in 
terms of significant digits 

Get Required format, such as field definitions 


Adaptation requirements. This paragraph shall be divided into 
subparagraphs as needed to specify any adaptation requirements 
for the CSCI, including, as applicable: 


a. Any site-unique data required by each installation 
bs Any parameters required by the CSCI that may vary according 
to operational needs 


Sizing and timing requirements. This paragraph shall specify: 


a. Sizing requirements on the CSCI, including, as applicable, 
amount/type/location of internal and auxiliary memory 
allocated to the CSCI; variations between normal operation 
and contingency operations; and other constraints imposed by 
the planned memory available to the CSCI. 


yy. Timing requirements on the CSCI, including, as applicable, 
amount of processing time allocated to the CSCI; required 
throughput time; required response time to queries and other 
requests; sequential relationships of CSCIs; sequential 
relationships of CSCI capabilities; priorities imposed by 
type of inputs and modes of operation; timing requirements 
for range of loads under varying operating conditions; and 
required input/output transfer times. 


Safety requirements. This paragraph shall specify any safety 
requirements applicable to the CSCI, concerning potential hazards 
to personnel, property, and the physical environment. 


Security and privacy requirements. This paragraph shall specify 
any security and privacy requirements applicable to the CSCI. 


These requirements shall include, as applicable: 


a. The type and degree of security or privacy of data to be 
used in or processed by the CSCI, including when the data 
become sensitive or change sensitivity. 


iy The type and degree of security or privacy of the algorithms 
that are permitted or required to be used in the CSCI. 


oe The security and privacy environment that can be assumed to 
exist during operation. 


Design constraints. This paragraph shall specify any other 
requirements that constrain the CSCI design, such as the use of a 
particular processing configuration. If there are no constraints 
imposed on the CSCI design, this fact shall be so stated. 
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Software quality factors. This paragraph shall be divided into 
subparagraphs as needed to specify any software quality factors 
identified in the contract or derived from a higher level 
specification and the method to be used to determine whether each 
quality factor has been met. These factors may include 
reliability (the ability to perform with correct, consistent 
results), maintainability (the ability to be easily corrected), 
availability (the ability to be accessed when needed), 
flexibility (the ability to be easily adapted to changing 
requirements), portability (the ability to be easily modified for 
a new hardware environment), reusability (the ability to be used 
in multiple applications), testability (the ability to be easily 
and thoroughly tested), usability (the ability to be easily 
learned and used), and other attributes. 


Human performance/human engineering requirements. This paragraph 


shall specify any human factors engineering requirements imposed 
on the CSCI. These requirements shall include, as applicable, 
consider-ations for: 


an Human information processing capabilities and limitations 

Dy. Foreseeable human errors under both normal and extreme 
conditions 

ce Implications for the total system environment (include 


training, support, and operational environment) 


Requirements traceability. This paragraph shall contain a 
mapping of the engineering requirements in this specification to 
the system requirements allocated to this CSCI, and a mapping of 
the system requirements allocated to this CSCI to the engineering 
requirements in this specification. 


Qualification requirements. This paragraph shall specify the 
qualification requirements necessary to establish that each 


requirement in 5.x.1 and 5.x.3 has been met. It shall include, 
as applicable: 


ar Definition of the qualification methods to be used (for 
example, demonstration, test, analysis, 
inspection) 
D. Assignment of one or more of these methods to each 
requirement 
GA Description of any special tests or examinations to be 
performed 


Preparation for delivery. This paragraph shall specify any 
requirements for delivery, including delivery media, labeling, 


packaging, handling, and classification markings. 


Interface requirements specification. This section shall be 
divided into the following paragraphs to specify the requirements 


for one or more interfaces between one or more CSCIs and other 
configuration items or critical items. These requirements may 
describe the interface characteristics of existing items or 
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specify the required interface characteristics of new or to-be- 
modified items. 


Interface requirements. 


Interface identification and diagrams. This paragraph shall 
identify the interfaces to which this specification applies. 


These items may include systems, other configuration items, and 
support software and hardware, such as utilities and test 
software, databases, and items in the communications environment. 
The identification of each item shall include its name, number, 
version, and documentation references. The identification shall 
state which items already exist (and therefore impose interface 
requirements on interfacing items) and which are being developed 
or modified (thus having interface requirements imposed on them). 
One or more interface diagrams, as appropriate, shall be provided 
to depict the interfaces. Each interface shall be identified by 
name and project-unique identifier, and shall specify, as 
applicable, the type of interface required (Sequential or 
concurrent operation, real-time data transfer, store-and-retrieve 
data transfer, operator controlled, etc.). 


(Interface name and project-unigue identifier). This paragraph 


(beginning with 6.1.2) shall identify an interface by name and 
project-unique identifier, shall state its purpose, and shall be 
divided into the following subparagraphs. When describing 
interface characteristics of existing items, read "established" 
for "required." 


Data element requirements. This paragraph shall specify any 
requirements pertaining to data elements to be transmitted 


between the interfacing items, including, as applicable: 


a. A project-unique identifier for the data element 

b; A brief description of the data element 

e The CSCI or other item that is the source of the data 
element, and an indication of which of these, if any, is 
imposing the requirement 

d. The CSCI(s) or other item(s) that are the recipients of the 
data element, and an indication of which of these, if any, 
is imposing the requirement 


e. The units of measure in which the data element must be sent 
or received 
£}, The limit/range of values that must be sent or received for 


the data element (for constants, the actual value; when 
applicable, allowable codes, message types) 


g. The accuracy that must be possessed by the data element 

h. The precision or resolution with which the data element must 
be sent or received, in terms of number of significant 
digits 

D, The timing characteristics with which the data element must 


be sent or received (how often transmitted or received, 
transmitted for how long, etc.) 
ak Legality checks the data element must be able to pass 
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de The data type (such as integer, ASCII, real, enumerated, 
etc.) in which the data element must be sent or received 


Le The data representation/format in which the data elements 
must be sent or received 
m. Sequence or other dependencies among the data elements 


Messages or other data assemblies. This paragraph shall specify 
any requirements concerning messages or other assemblies of data 


elements to be transmitted between the interfacing items. It 
shall identify each such message or assembly by name and project- 
unique identifier and shall describe the assignment of data 
elements to each message or assembly. 


Interface priorities. This paragraph shall specify any 
requirements concerning the relative priority of the interface, 
data elements, messages, or assemblies transmitted between the 
interfacing items. 


Interface/communication protocols. This paragraph shall be 


divided into subparagraphs as needed to specify any requirements 
concerning commercial, military, or proprietary communications 
protocols to be used for the interface. It shall identify each 
protocol to be used and shall specify for each, as applicable, 
requirements for: 


a. Fragmentation and reassembly of messages 

be Message formatting 

Cr Legality checks, error control, and recovery procedures, 
including fault tolerance, handling of "out-of-bounds" 
conditions, and continuity of operations in emergencies 

ote Synchronization: connection establishment, maintenance, 
termination, timing 

e. Flow control, including sequence numbering, window size, and 
HuLCcereatLocat 1 On 

im Data transfer rate, periodic or aperiodic, and minimum 


interval between transfers 

Ge Routing, addressing, and naming conventions 

hi. Transmission services, including priority and grade 

aha Status, identification, notification, and any other 
reporting features 

ae Security and privacy, including encryption, user 
authentication, compartmentalization, and auditing 


Qualification requirements. This paragraph shall be divided into 
subparagraphs as needed to specify the qualification requirements 


necessary to establish that each requirement in 6.1 has been met. 
It shall include, as applicable: 


a. Definition of the qualification methods to be used (for 
example, demonstration, test, analysis, inspection) 

ae Assignment of one or more of these methods to each 
requirement 

rel Description of any special tests or examinations to be 


performed 
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Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 


information, glossary, rationale). This section shall contain an 


alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document, and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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DOCUMENT: BLM C-8001S5B 


CONSOLIDATED SOFTWARE TEST 
DOCUMENT (C-STD) 


Alternate For: 


Software Test Plan - BLM 80014B 
Software Test Descriptions - BLM 80015B 
Software Test Report - BLM 80017B 
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PURPOSE: 


CONTENTS : 


BLM C-80015B 


CONSOLIDATED SOFTWARE TEST DOCUMENT (C-STD) 


The Consolidated Software Test Document (C-STD) is a single 
document encompassing the test planning, test cases and 
procedures, and test results for CSCI, CSCI integration, and 
software system testing, as applicable. 


It contains, in summary form, the contents of the Software Test 
Plan (STP), Software Test Description(s) (STDs), and Software 
Test Report(s) (STRs) for a project. 


A C-STD is written as an alternative to the individual testing 
documents cited above. It is best suited to a project on which a 
Single test document is most effective. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." 


Document Structure: 


Ls Scope 
1.1 Identification 
1.2 System overview 
1.3 Document overview 


22 Referenced documents 
ie Software test planning 
3.1 Software test environment 
chee ee (Name of test site(s) ) 
3.2 Test identification 
Bi ere General information 
SZ 2 Planned tests 


Spee eek (Item(s) to be tested) 
3.2.2.x.y (Test name and 


identifier) 
3.3 Test schedules 
4. Software test descriptions 
4.x (Item(s) to be tested) 
Aner Test preparations 
Ai elas V (Test name and identifier) 
ANXez Test descriptions 
Ar. Y. (Test name and identifier) 


4.x.2.y.z (Test case name and 
project-unique Identifier 


5. Software test report 
5.x (Item(s) tested) 
Bixee Test overview 
Sexe Lay. (Test name and identifier) 


5,x.2 Detailed test results 
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Scope. This section shall be divided into the following 
paragraphs. 


Identification. This paragraph shall contain a full identific- 
ation of the system and the CSCIs to which this document applies, 
including, as applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release number(s). 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
Maintenance; identify the project sponsor, user, developer, and 
Support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


Software test planning. This section shall be divided into the 
following paragraphs to describe the contractor’s plans for 
conducting CSCI, CSCI integration, and software system testing. 


Software test environment. This paragraph shall be divided into 
subparagraphs as needed to describe the software test environment 
at each intended test site. Reference may be made to the software 
engineering environment described in the software development 
plan for those resources that are used in both environments. 


(Name of test site(s)). This paragraph shall identify one or 
more test sites to be used for the testing, and shall describe 
the software test environment at the site(s). The description of 
each test environment shall include the following: 


a. Name/identifier and version of software items (e.g., 
operating systems, compilers, communications software, 
databases, test drivers, preprocessors, other special test 
software), including the purpose of each, any security and 
privacy considerations, and which are to be provided by the 
site. 


(5%! Name/model/serial number and version of hardware and 
firmware items (e.g., computer hardware, interfacing 
equipment, communications equipment, test message 
generators, test timing devices, etc.), including the 
purpose of each, any security and privacy considerations, 
and which are to be provided by the site. 
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CR Other materials needed for the testing (e.g., manuals, 
listings, the software to be tested, data to be used in the 
tests, sample outputs, test worksheets, etc.), including the 
purpose of each, any security and privacy considerations, 
and which are to be provided by the site. 


oe The proprietary nature and Government rights associated with 
each item of the software test environment. 


e. Plans for installation, testing, and control of the software 
test environment. 


e. The organizations that will participate in the testing. 


a. The number and skill types of personnel required during the 
test period, and the dates and time they will be needed. 


aks Plans for any orientation and training to be given before 
and during the testing. 


ak The tests to be performed at the site(s), indicated by 
references to paragraph 3.2. 


Test identification. 


General information. This paragraph shall provide the following 
general information about the testing to be performed: 


a. Levels of tests of be performed (e.g. CSCI, CSCI 
integration, system) 

b. Types or classes of tests to be performed (e.g., stress 
tests, timing tests, erroneous input tests, maximum capacity 
tests) 

‘oe Any test requirements that apply to all, or a group of, 
tests (e.g., "Tests of type x shall use live data") 

ce Extent of testing to be performed (e.g., specified sampling 


of possible inputs) and rationale for the extent selected 
e. Planned sequence or progression of tests 


ce The data recording, reduction, and analysis procedures to be 
used during and after the tests 


Planned tests. 


(Item(s) to be tested). This paragraph shall identify a CSCI, 
group of CSCIs, subsystem, system, or other entity by name and 


project-unique identifier, and shall be divided into the 
following subparagraphs to provide an overview of the tests 
planned for that item. (Note: "tests" are collections of test 
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cases. There is no intent to describe each test case in this 
paragraph.) 


(Test name and identifier). This paragraph shall identify a 
test by name and project-unique identifier, and shall be divided 
into subparagraphs as needed to specify: 


a. Test objective 

b; Test level (using the test levels defined above) 

C Test class (using the test classes defined above) 

d Qualification method(s) specified in the associated 
requirements specification (s) 

Cross reference to the software requirements addressed by 
this test 

Any special test requirements 

Type of data to be recorded 

Type of data recording/reduction/analysis to be employed 
Assumptions and constraints 

Any security and privacy considerations 


0) 
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Test schedules. This paragraph shall contain or reference the 
schedules for conducting the tests identified in this plan. The 
schedules shall include: 


ay Time frame for testing at each test site 

b. Test schedule for each test site, including pretest 
activities, preparation of test inputs and databases, any 
orientation or training associated with the testing, the 
testing itself, and any period for review/approval of test 
results 


Software test descriptions. This section shall be divided into 
the following paragraphs to describe the test cases and test 
procedures to be used for CSCI, CSCI integration, and software 
system testing. 


(Item(s) to be tested). This paragraph shall identify an item to 
be tested and shall be divided into the following subparagraphs 
to describe the tests for that item. 


Test preparations. This paragraph shall be divided into the 
following subparagraphs to describe test preparations. Security 
and privacy considerations shall be included as applicable. 


(Test name and identifier). This paragraph shall identify a test 
by name and identifier, and shall be divided into subparagraphs 
as needed to provide the following information: 


a. Test schedule, if updated or more detailed than that given 
in paragraph 3.3 

Pre-test procedures for hardware preparations 

Pre-test procedures for software and data preparations 

: Other pre-test preparations 
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Test descriptions. This paragraph shall be divided into the 
following subparagraphs to provide test descriptions for the 
item(s) under test. Security and privacy considerations shall be 
included as applicable. 


(Test name and identifier). This paragraph shall identify a test 
by name and project-unique identifier and shall be divided into 
the following subparagraphs. 


4.x.2.y.z (Test case name and project-unique identifier. This subparagraph 


shall identify a test case by name and project-unique identifier 
and shall provide the following information for the test case: 


a. Purpose/traceability: cross-reference to the software 
requirements addressed by the test case 


by Means of control to be used: manual, semi-automatic, or 
automatic insertion of inputs and control of test sequence 


Cr Prerequisite conditions that must be established: 
hardware/software initialization or other initialization 


a. Test inputs: description, source, real vs simulated, 
timing/sequence, means of control 


e. Expected results, both intermediate and final, as applicable 


te Criteria for evaluating the results: acceptable limits for 
tolerances, sample sizes, durations, number of breaks, 
severity of problems, status indicators 


ge Test procedure: numbered steps to be followed in 
initiating, carrying out, and analyzing the results of the 
test case, including, as applicable, alternative actions, 
expected results, and evaluation criteria for each step 

he Any assumptions or constraints applicable to the test case 


Software test report. This section shall be divided into the 
following paragraphs to describe the results of CSCI, CSCI 
integration, and software system testing. 


(Item(s) tested). This paragraph shall identify an item under 
test and shall be divided into the following subparagraphs to 
describe the results of the tests for that item. 


Test overview. 


(Test name and identifier). This paragraph shall identify a test 
by name and project-unique identifier and shall be divided into 


subparagraphs as needed to provide the following information: 


ax A summary of test results, including the completion status 
of the test (for example, "all results as expected," 
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"problems encountered," "deviations required") and, when the 
completion status is not "as expected," a summary of the 
problems or deviations that occurred and reference Section 
to 5.x.2 for details 


D: Reference to a figure, appendix, or other presentation of a 
chronological record of test events, including dates, times, 
locations, hardware and software configurations used, 
activities, and test performers and witnesses, as applicable 


Detailed test results. This paragraph shall be divided into the 
following subparagraphs to describe the detailed results of each 
test. 


(Test name and identifier). This paragraph shall identify a test 
by name and project-unique identifier and shall be divided into 


subparagraphs as needed to provide the following information: 


a. The completion status of each test case associated with 
this test (e.g., "all results as expected," "problems 
encountered," "deviations required") 

lee A description of each problem encountered, including the 


test case and test procedure step where it was encountered 
and reference to the associated problem report (s) 


CG. A description of each deviation from the documented test 
cases/test procedures, including test case and test 
procedure step where the deviation occurred, nature of the 
deviation, rationale, and an assessment of its impact on the 
validity of the test case 


Evaluation and recommendations. This paragraph shall be divided\ 
into the subparagraphs as needed to provide: 


ae An overall assessment of each item under test, summary of 
remaining deficiencies or limitations, impact if the 
deficiencies/limitations are not corrected, and impact to 
correct them 


ie An assessment of the manner in which the test environment 
may be different from the operational environment and the 
effect of this difference on the capabilities tested 


el Any recommended improvements in the design, operation, or 
testing of the item(s) under test (optional) 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary). This section shall include an 
alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 
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Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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SOFTWARE TEST REPORT 
(STR) 
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SOFTWARE TEST REPORT (STR) 


PURPOSE: The Software Test Report (STR) is a record of the 
testing performed on a Computer Software Configuration 
Item (CSCI), an integrated group of CSCIs or 
CSCIs/HWCIs, a software system or segment, or other 
software-related item. An STR provides a permanent 
record of the testing and its results. 


CONTENT: This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
Test Document and Completely Consolidated Software 
Development Record). Only one of these three DIDs 
should be applied to a given set of data. 

Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." 


DOCUMENT STRUCTURE: 


9 Tc Scope 


iglor identification 

1.2 System overview 

1.3 Document overview 
1.4 Security and privacy 


2e Referenced documents 
38 Test overview 
3.x (Test name and project-unique identifier) 
3axel (Test name) summary 
Bx Z (Test name) test record 
4.x (Test name/identifier) test results 
Avex. Test case results 
Ae SZ Problems encountered 
4.X.2.y (Test case 
name/identifier) 
4.x.3 Deviations from test 
cases/procedures 
4..X238V (Test case 
name/identifier) 
Ls) 5 Evaluation and recommendations 


5.2) Evaluation 

5.2 Impact of test environment 

5.3 Recommended improvements 
6. Notes 
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1K Scope. This section shall be divided into the 
following paragraphs. 


ae. Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


2 System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


3 Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


1.4 Security and privacy. This paragraph shall describe 
any security and privacy considerations associated with 
the test analysis and the data being handled. 


2. Referenced documents. This section shall list by 
document number and title all documents referenced in 
this report. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


ce Test overview. This section shall be divided into the 
following paragraphs to summarize the results of each 
test covered by this report. Note: The word "test" 
means a related collection of test cases. There is no 
requirement to report on each test case in this 


section. 
Cue (Test name and project-unique identifier). This 


paragraph shall identify a test by name and number, and 
shall be divided into the following subparagraphs to 
provide an overview of the test results. 


ee ts 1 (Test name) summary. This paragraph shall summarize 
the results 


of the test. The summary shall include the completion 
Status of the test (for example, "all results as 
expected," "problems encountered," "deviations 
required." When the completion status is not "as 
expected," this paragraph shall summarize the problems 
or deviations that occurred and reference Section 4 for 
details. 


See eae (Test name) test record. This paragraph shall present, 
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in a figure or appendix, a chronological record of test 
events. This record, which may be in the form of a 
test log, shall include: 


a. The date(s), time(s) and location(s) of the test. 
jays The hardware and software configurations used for 
the test 


including, as applicable, part/model/serial 
number, manufacturer, revision level, and 
calibration date of all hardware, and version 
number and name for the software components used. 


Ca The date and time of each test-related activity, 
the 

identity of the individual(s) who performed the 
activity, and the identities of witnesses, as 
applicable 4. Detailed test results. This 
section shall be divided into the following 
paragraphs to describe the detailed results for 
each test. 


(Test name/identifier) test results. This paragraph 
shall identify a test by name and project-unique 
identifier, and shall be divided into the following 
subparagraphs. 


Test case results. This paragraph shall present, 


possibly ina 


4.X.2 
aipabene) 


Ax. 2 
ident 


table, the completion status of all test cases 
associated with this test. The completion status shall 
be, for example, "all results as expected," "problems 
encountered," "deviations required." 


Problems encountered. This paragraph shall be divided 


subparagraphs that identify each test case in which one 
or more problems occurred. 


ny. (Test case name/identifier). This paragraph shall 
ify a 
test case in which one or more problems occurred, and 
shall provide: 


Meera A brief description of the problems(s) that 
occurred. ley Identification of the test procedure 
step(s) in which they 

occurred. 
cr Reference(s) to the associated problem report (s). 
‘els The number of times the procedure or step was 


repeated in 
attempting to correct the problem(s) and the 
outcome of each attempt. 
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4.X.3.y 


e. Backup points or test steps where tests were 


resumed for 


retesting. 


Deviations from test cases/procedures. This paragraph 
divided into subparagraphs that identify each test case 


in which deviations from test case/test procedures 
occurred. 


(Test case name/identifier). This paragraph shall 


identify a 


correct it 


test case in which one or more deviations occurred, and 
shall provide: 


a. A description of the deviation(s) (for example, 


substitution 


Or 


of required equipment, changes to support 
software, procedural steps not followed, schedule 
deviations). (Red-lined test procedures may be 
used to show the deviations). 


| aye The rationale for the deviation(s). 
ak An assessment of the deviations’ impact on the 
validity of 

the test case. 


Evaluation and recommendations. This section shall be 
divided 
into the following paragraphs. 


Evaluation. This paragraph shall: 


a. Provide an overall assessment of the software as 
demonstrated by the test results in this report. 


be Identify any remaining deficiencies, limitations, 
constraints that were detected by the testing 
performed. Software problem/change reports may be 


used to provide deficiency information. 


c For each deficiency, limitation, or constraint, 


describe: 


1) Its impact on software and system performance 
2) The impact on software and system design to 
2) A recommended solution/approach for 


correcting it 


239) 


Pe 


Impact of test environment. This paragraph shall 
provide an assessment of the manner in which the test 


environment may be different from the operational 
environment and the effect of this difference on the 
capabilities tested. 


7 


Pay - [ 


sy, a OE) S21 le 2ag \SsRh 2855 f 


‘Stanebt Jade atiqgsiebss quite osnt bontvin 
a i\Sseen Jae] & 3 ri otjsiveb Hd5ide a 


. bewsuD$o 
nite . 
ea 4 =» - a 
z ES tigen? BE saAa weevil ¢ 
=) “CG .* biter riz SBA5 tao a 
abivcuid ilede 
| | | to oolsgisonead 4 7: 
Ljnsted 
Bi OG a rm. 5 _ _ 
~ ¥ roe = 8 
in 1B Ven = 
; 1 Sey 
ss Ont u 
re 6. ThA 5 
' ay Pf fov 
oc. SH 
ho dade! : 
Dac iy BD 
i s,. a3 at 
‘ j . of iva 
; > Fi ) 
. =d 
tO 
pS is j 
; ont 4 
* | SL. 1 j 
10% ‘ «9 
ect ieveet. |) 
: ry ie 
od 4 ia : 
49 508 ay '™ 
Oe as i. 3 


34 
costed eid? josie ives 1682.20 08 


dotaw at tennem edo to ofeneeseees rat ve aa 
itexsgo 543. mos) Jossesiib sd Yar tute vis 

xe onus tsi3lS Bid? to.4e%$s edd Bane nt st 
. boteos 


>) 


Recommended improvements. This paragraph shall provide 
any recommended improvements in the design, operation, 

or testing of the item(s) under test. A discussion of 

each recommendation and its impact on the items may be 

provided. If no recommended improvements are provided, 
this paragraph shall state "None." 


Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of any terms and definitions needed 
to understand this document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENTS : 


BLM 80019B 


SOFTWARE USER MANUAL (SUM) 


The Software User Manual (SUM) tells a hands-on 
software user how to install, initiate, use, and 
terminate the software in a single CSCI, a group of 
related CSCIs, or an overall software system. 


A SUM is developed for software that is run by the user 
and has a user interface requiring on-line user input 
or interpretation of displayed output. The SUM is an 
alternative to the Software Input/Output Manual (SIOM), 
which is developed for software that runs in a computer 
center and is accessed via terminals or by submitting 
batch inputs and receiving batch reports. 


This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
User/Operator Manual) and Completely Consolidated 
Software Development Record). Only one of these three 
DIDs should be applied to a given set of data. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." For data delivered in an alternative 
form, this representation need occur only in the table 
of contents or equivalent. 


DOCUMENT STRUCTURE: 


Le, Scope 
ivi LoOenti fication 
1.2 System overview 
1.3 Document overview 
1.4 Security and privacy 


Zo Referenced documents 
as Software summary 
3.1 Overview 
rele cd Application summary 
3h a2 Performance 
Seu Controls 
3.2 Software environment 
angel Hardware required 
See Software required 


3.3 Contingencies/alternate modes of operation 
3.4 Assistance and problem reporting 
4. Access to the software 
4.1 First-time user of the software 
rep loeb Equipment familiarization 


* : 


ia }3) 


wil 10g 


a pscclovab ek MUZ A ¢ 
= Sean youu 5 usd bas 
> nolisjetazstal +0 
°5o6 eft of evissqverts 
roi Gsoecfeveb eat doldw 
Fa5De 2 bas 67089 
: * base aitoool. doded 
* j is) @knT 
< j 544 ig 3 orcs 
inG acaT 
3 O\2eau 
) #rewidto2 
> j pluwor aCtd 
j iIszpaeset 
" e Si]<2ee3 
é Sf fs 
¥< EY y ol 63 
+ , Bind » > 
4 cs } bite) - 
ITQUaTS THeMUROG 
é a _f 
sf 7 p is a - i 
Sivi+e Jee £ 
avo tdIncemood r 
i 4a Y= 
Sy] . Ben ea) | *.~ 
Riis 2 - o8 .t 
7= Ls J fe: 
ol sso tics J 
4 as ae | 2 A ¢ 
fos i tf 
mroxz ive  <t4ns1ic8a St 
£ ry swir28 foe. & 
Pers Yew TIOE he > £ 
SF mit stale onspuivzac) . tut a 


naidoxqg base sonsdateck bE) 

s1GwWiI10G e872 oF #8405 
{o8 sft to senu emid-+deqrt 
siitms? sremyivps) 


mt 7 
it 


su TLOR 


teaU" dcanigon a 
vou 2seu Rigen 
nth essa tore? 
20 2) Geislox 


7 


it 


iy 
_ 


4.2 
4.3 


4x12 Access control 

4.1.3 Installation and setup 
Initiating a session 

Stopping and suspending work 


Processing reference guide 


5.1 Capabilities 
5.2 Conventions 
5.3 Processing procedures 
Soh oC Variable title (Identify) 
5.4 Related processing 
5. 5eeData backup 
5.6 Recovery from errors, malfunctions, and 
emergencies 
5.7 Messages 
Notes 


Appendixes 
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Scope. This paragraph shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this manual. 


Security and privacy. This paragraph shall contain an 
overview and discussion of the security and privacy 
considerations associated with the software. A 
warning shall be included regarding making unauthorized 
copies of data, documents, or software, if applicable. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this manual. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


Software summary. This section shall provide a 
nontechnical description of the software described by 
this manual. Detailed technical information should be 
presented in other sections. 


Overview. 
Application summary. This paragraph shall describe the 


the software in supporting the activities of the user. 
The description shall include major functions performed 
by the software such as preparation of output, 
Maintenance of data, and display of information. This 
presentation, part of which shall be presented as a 
general system flowchart shall show, as applicable: 


a’ Logical parts of the software from the point of 


view of the 


user 
bi Communication paths and techniques 
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ots Interfaces to other systems or software 
oR The organizations that provide input to the 


software or that 


oan 
software 


ek 


receive output from it 
Performance. This paragraph shall describe the 
performance characteristics that can be expected by the 
user. -Characteristics such as capacity constraints and 
times needed to accomplish major functions shall be 
included. 


Controls. This paragraph shall briefly describe the 


supervisory 


ie. 2 
briefly 


controls that can be implemented to manage the 
software. 


Software environment. 
Hardware required. This paragraph shall identify and 


discuss the hardware that must be present for the 
software described in this manual to run. Options for 
the use of additional hardware shall also be 
identified. 


Software required. This paragraph shall identify and 


discuss any other software that is necessary to use the 
software described in this manual. This software may 
include the operating system, utilities, and other 
supporting systems. 


Contingencies/alternate modes of operation. This 


paragraph shall explain the general nature of the 
differences expected in what the user will be able to 
do with the software at times of emergency and what the 
user will be able to do based on modes of operation 
that differ between peacetime, war, and conditions of 
alert. 


Assistance and problem reporting. This paragraph shall 
identify points of contact and procedures to be 


followed to obtain assistance and report problems 
encountered in using the software. 


Access to the software. This section shall contain 
detailed step-by-step procedures oriented to the first 
time/occasional user. Enough detail shall be presented 
so that the user can reliably access the software 
before learning the details of its functional 
capabilities. 


First-time user of the software. 
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Equipment familiarization. This paragraph shall 


following as appropriate: 


eur Procedures for turning on power and making 
adjustments ea Dimensions and capabilities of the 
visual display screen Cs Appearance of the cursor, how 
to identify an active cursor 
if more than one cursor can appear, how to 
position a cursor, and how to use a cursor 
a Keyboard layout and what is accomplished by 
different types 
of keys and pointing devices 
e. Procedures for turning power off if special 
sequencing of 
operations is needed 


Access control. This paragraph shall present an 


overview of the 


any 


access and security features of the software that are 
visible to the user. The following items shall be 
included, as applicable: 


a. How and from whom to obtain a password 
be How to add, delete, or change passwords under user 
control c. Security and privacy considerations 


pertaining to the 
storage and marking of output reports and other 
media that the user will generate 


Installation and setup. This paragraph shall describe 


special procedures that the user must perform in order 
to be identified or authorized to access or install 
software on the equipment, or to enter parameters for 
software operation. 


Initiating a session. This paragraph shall provide 
step-by-step procedures for beginning work, including 
any options available. A checklist for problem 
determination shall be included in case difficulties 
are encountered. 


Stopping and suspending work. This paragraph shall 
describe how the user can cease or interrupt use of the 


software and how to determine whether normal 
termination or cessation has occurred. 


Processing reference guide. This section shall provide 
the user with technical information on processing 
procedures. If procedures are complicated or 
extensive, additional Sections 6, 7,... may be added 
in the same paragraph structure as this section. The 
organization of the document will depend on the 
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characteristics of the software being documented. For 
example, if the tasks of users vary depending upon the 
organization echelon in which they work, Section 5 
might be oriented to headquarters functions and Section 
6 to remote site functions. For other software, it may 
be more appropriate to have Section 5 be a guide to 
menus used in the system, Section 6 be a guide to 
command language used in the system, and Section 7 be a 
guide to functions. Detailed procedures are intended 
to be presented in subparagraphs of paragraph 5.3. 
Depending on the design of the software, the 
subparagraphs might be organized on a function-by- 
function, menu-by-menu, or other basis. Fora 
transaction-oriented system the organization might be 
on a screen-by-screen basis. 


Capabilities. This paragraph shall briefly describe 
the interrelationships of the transactions, menus, 
functions, or other processes in order to provide an 
overview of the use of the software. 


Conventions. This paragraph shall describe any 
conventions such as the use of colors in displays, the 
use of audible alarms, the use of abbreviated 
vocabulary, and the use of rules for assigning names or 
codes. 


Processing procedures. This paragraph shall explain 
the organization of subsequent paragraphs, e.g., by 
function, by menu, by screen. Any necessary order in 
which procedures must be accomplished shall be 
described. 


Variable title (Identify). The title of this paragraph 


identify the function, menu, transaction, or other 
process being described. This paragraph shall describe 
and give options and examples, as applicable, of menus, 
data entry forms, user inputs, inputs from other 
software or hardware that may affect the software’s 
interface with the user, outputs, diagnostic or error 
messages or alarms, and help facilities that can 
provide on-line descriptive or tutorial information. 
The format for presenting this information can be 
adapted to the particular characteristics of the 
software, but a consistent style of presentation shall 
be used, i.e., the descriptions of menus shall be 
consistent, the descriptions of transactions shall be 
consistent among themselves. 


Related processing. This paragraph shall identify and 
describe any related batch, offline, or background 
processing performed by the software that is not 
invoked directly by the user and is not described in 
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paragraph 5.3. Any user responsibilities to support 
this processing shall be specified. 


Data backup. This paragraph shall describe procedures 
for creating and retaining backup data that can be used 
to replace primary copies of data in event of errors, 
defects, malfunctions, or accidents. 


Recovery from errors, malfunctions, and emergencies. 
This paragraph shall present detailed procedures for 


restart or recovery from errors or malfunctions 
occurring during processing and for ensuring continuity 
of operations in the event of emergencies. 


Messages. This paragraph shall list, or refer to an 
appendix that lists, all error messages, diagnostic 
messages, and information messages that can occur while 
accomplishing any of the user’s functions. The meaning 
of each message and the action that should be taken 
after each such message shall be identified and 
described. 


Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of terms and definitions needed to 
understand this document. If section 5 has been 
expanded into section(s) 6,...n, this section shall be 
numbered as the next section following section n. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENTS : 


BLM 80031B 


SOFTWARE INSTALLATION PLAN (SIP) 


The Software Installation Plan (SIP) is a plan for 
installing a new or modified software system at user 
Sites, including preparations, user training, and 
conversion from existing systems. 


A SIP is developed when installation of a new or 
modified system, consisting of software alone or 
software and associated computer equipment, will be 
sufficiently complex to require a documented plan. For 
software and computer resources embedded in a larger 
system, a fielding or deployment plan for the larger 
system may make a separate Software Installation Plan 
unnecessary. 


It contains specific information required for each 
specific site for both software, hardware, and 
preparation instructions. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." 


Content requirements. Content requirements begin on 
the following page. The numbers shown designate the 
paragraph numbers to be used in the document. Each 
such number is understood to have the prefix "10.2" 
within this DID. For example, the paragraph numbered 
1.1 is understood to be paragraph 10.2.1.1 within this 
DID. 
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ine Scope 
to “Edentiftication 
1.2 System 
1.3 Document overview 


2.Referenced documents 


nstallation overview 
.1 Description 


Su 


Personnel orientation 


if 
3 
e) 
3 
Be 
| 
3 
3 Personnel requirements 


foam Ontacl point 

-3 Support materials 
4 Training 

-5 Tasks 

25 

our 


Ped 


15) aes? ha Me oy 
2) WAIG: wk iia tticeted asAwtGOR! = 
_ 
, SES) els aot iatiases mprieer ce :] 
3 oe sbal Fiber aes @ priiistenk 
+ “buuc aoekssreqesq palbuloar® ,asdie 
Lays Bo seve ots six moxt} To taewne 
R fer. 2 ee 2) 
morse lack ccs ay ee al qIP & 
Oo otételiacoo .meJevarbélizrbom 
bepecn sig iooese bOb Sstewttoe 
i: cpee a4 xelemop yess rol tioe 
yoodiwangen raadss: yetuvomes, Bask esewiice 
Sees neevo los) to palbiery & \mieseve 
ISS B&B BFA Yom mealeye 
. ¥ TSHBe50S00U 
: (seqe entetogoo 2 
(ot o¢fe o27 55908 
no* JBLSeQeitg 
I SIQBIPSSEY 
iy n=: J2Lvees 
; sob eos ni 
OS30L 582 
tre TAO 
A acts 
T cs 12) Hq - 
iminr cous 
oi Pit | bw 
Dt iy ef isk 
meets! 
Bia ir ei: mace 
wI058 cm 
} eb J ar 4 
; 2 ae « 
‘ i Bed 
3 sob batiwreted.& 
welvisve Jelis2eet +b 
"0.3 1279890 Lf. | 
Jcica. JourtnoOD S.€ 
eaisiusian J10qquE E.é : 


soljatnelico ea et 
ejnensziopet L¢ ae 7 


3.8 Security and privacy 


Site information-computer operations 
4.x (Site name) 

4tx01 Schedule 
Software inventory 
Facilities 
Installation team 
Detailed procedures 
Data update procedures 


NU PWD 


Site information - users 
5.x (Site name) 


Sexe 1 Schedule 
Bixee Detailed procedures 
5ax3 Data update procedures 


Notes 


Appendixes 


ae 
7 


ost \ x aq 
Fike af Oar er LPT AS 
oe ae ie ela 
ea Int * oo yeesmewil & 


ae ei ae . es 
Sexy batiisted 
eye re vt Li sp Saonio"*saeboulrsgsa * 
dayne ae ere ene a» MAAS 
wares . 1+ aviusgea |eeneal ~. sak 
ade . ae Pit, ZENE S, ‘ Te 3 | Sembreacy 
“go 7° 8? 710° Reine ~ 
= 2.  cOnetebesore beisss az 
Ms) at (aaiobanc 24 sijebgu Ste 
oy 
pwd r 
; 
ty, 4 . cir a 5 
ae 2 i ey, FB “hi ¥y | C18 
Poe a ea OE eet tie A Certs. 
3 BI ot) Oe Ake 5 7 
: aS iv : my 7 
Sen ter ys eh 6G a ees 
TAD WERE a | ee Fe cone eee uae ak 


4 oe sy, 
D ie a a 
i 1. ." 
AL RG es) 
i * we Wy. at os we 
pu EPR DOTS 3 ; 
Peter aya afoon, é Re is aye ® 
Oe «wt : ‘ee va re ES SPE: oP 1 
te c ae | ae | aay 
a hd ok x 
ee ae 3 ae ae ‘ 
Ea? + Ey a 42h S Lh abe * 
Pigs Come; Mase ty, |e 
PTO SAC ray 5. 2 ory : 
gas bee pea oe ‘ 
Ver - mI 
=f 6 
ie Ad 4R Tk 


AB. Tea as. ee Se 
255, SPCR ALS Pea) amee 3 
. * < fe depet: 


ree PAOMORVES Q Sas gs) suze 


{2 30emio9 “OR smms0 AE 
ties 
mT rebarlos 


r grt gery 


12 


e 
Ne 
2 
ty F 
a) hte 4 
ws ot 
; 
o 
> 3 
& . 
vi? 
os Me 
: 
> & c= - 


Pathe 


$amxolins” garg 


or os | 
eit te 5 
$.%.* 3 
: < x.é ¥ 
a. RB ret 
= See Seat 7 


-” 


o928Y *x.@°0 6° 


rinia*? ae 7 
Sse Ca 
>a e. MES : Tr 
esj7ouw. .2 
asx bosecr mY 
rl i* Ly 
rt ral Bal 
, = . x2 ieee 
ee tage ee 


© 
“ & 
f : coor & 
< hy nd 
Paes a 
; Catied 
oA ‘ 
Fi y 4 Fi r 
s meh f = te 
Palit, “W..# 
Sie! a 
Mor ‘ar ‘ 
3? Shae eo 
Ee 
se 5 Reo 
at a 
: * ot Yoae oe saa 
“ 1 a * at 
4 t i RE ef ae tS “ae 
a . 24 Doge ch, a er 
AeWets gt co 2s 
“ ae aol . 2 
We oh 
ed zy a he t st “S 
‘ 
© ae ' = op % we mrt 5 
Mme OF =) nd 
* . : 


: Meri a 
is —_ a an 4 


% 
q flea 
u 
7 : 
‘a a 
. 


Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this plan. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this plan. This section shall also identify the source 
for all documents not available through normal 
Government stocking activities. 


Installation overview. This section shall be divided 
into the following paragraphs to provide an overview of 
the installation process. 


Description. This paragraph shall provide a general 
description of the installation process to provide a 
frame of reference for the remainder of the document. 
A list of sites for system installation, the schedule 
dates, and the method of installation shall be 
included. 


Contact point. This paragraph shall provide the 
organizational name, office symbol/code, and telephone 
number of a contact for questions relating to this 
installation. 


Support materials. This paragraph shall list the type, 
source, and quantity of support materials required for 
the installation. Included shall be items such as 
Magnetic tapes, disk packs, computer printer paper, and 
special forms. 


Training. This paragraph shall describe the type and 
amount of special training required, if any. 
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Tasks. This paragraph shall list or describe in 
general terms each task required for the system 
installation. Each task shall be identified with the 
organization that will accomplish the task, usually 
either the user, computer operations, or the 


developer. This task list or description shall include 
such items to be accomplished as: 


a. Providing overall planning, coordination, and 
preparation 
for installation 

D> Ensuring that all manuals applicable to the 


installation are 
available when needed 


ce Providing technical assistance 
d.. Establishing criteria, supervising, and conducting 
training 
activities associated with the installation 
e. Scheduling processing required for the 
installation 
fc Providing comprehensive support for the 
installation 


‘ Ensuring that all prerequisites have been 

fed tal Lediprioxd to 

the installation date 
he Providing personnel for the installation team 
As Arranging lodging, transportation, and office 
facilities for 

the installation team 
he Providing instructor/student personnel for 
training before 

and during the installation 


Ks Providing computer support 
ai Providing priority scheduling to ensure adequate 
turnaround 


Personnel orientation. This paragraph shall identify 
those efforts such as briefings and seminars intended 
to orient personnel to the new system. 


Personnel requirements. This paragraph shall describe 
the number, time, and skill level of the personnel 
required during the installation period, including the 
need for multishift operation, clerical support, etc. 


Security and privacy. This paragraph shall contain an 
overview of the security and privacy considerations 
associated with the system. 


Site information - computer operations. This section 
applies if the system will be installed in computer 


center(s) for users to access via terminals or using 
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batch inputs/ outputs. If this type of installation 
does not apply, this section shall contain the words 
"Not applicable." 


(Site name). This paragraph shall identify a site or 
set of sites and shall be divided into the following 
subparagraphs to discuss those sites. Multiple sites 
may be discussed together when the information for 
those sites is generally the same. 


Schedule. This paragraph shall present a schedule of 
activities 

to be accomplished during installation. It shall 
depict the required tasks in chronological order with 
beginning and ending dates of each task with supporting 
narrative as necessary. | 


Software inventory. This paragraph shall provide.an 
inventory of 

the software required to support the installation. The 
software shall be identified by name, identification 
code or acronym, and security classification. This 
paragraph shall indicated whether the software is 
expected to be on site or will be delivered for the 
installation and shall identify any software to be used 
only to facilitate the installation process, 


Facilities. This paragraph shall detail the physical 
facilities 

and accommodations required during the installation 
period. This description shall include the following, 
as applicable: 


a. Classroom, work space, and training aids needed, 
specifying 
hours per day, number of days, and shifts 


bs Hardware that must be operational and available 
ol The availability of transportation and lodging for 
the 


installation team 


Installation team. When an installation team is 
required, this 

paragraph shall describe its composition. Each team 
member’s tasks shall be defined. 


Detailed procedures. This paragraph shall be divided 
into 

subparagraphs to present the step-by-step procedures 
required to accomplish the installation, including 
conversion. References may be made to other documents, 
such as operator manuals. The procedures shall 
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include the following, as applicable: 


Control inputs 

Operating instructions 

Communications 

-Database/data bank 

Output reports 

Special handling 

Diagnostic messages 

Procedures for restart/recovery and continuity of 
operations 

in emergencies 


yraMdAA OW 


4.X.6 Data update procedures. This paragraph shall be 
divided into 
subparagraphs to present the data update procedures to 
be followed during the installation period. When the 
data update procedures are the same as the normal 
updating or processing procedures, reference may be 
made to other documents, such as operator manuals. 
The procedures shall include the following, as 


applicable: 

a. Control inputs 

Da Operating instructions 

Cs Database/data bank 

d. Output reports 

e. Special handling 

ri Diagnostic messages 

g. Procedures for restart/recovery and continuity of 


operations 
in emergencies 


Be Site information - users. This section shall provide 
users with the information necessary to accomplish an 
orderly installation. When more than one type of user 
is involved, a separate section (Sections 6 through n) 
may be written for each user and the section titles 
modified to reflect each user. 


aioe, (Site name). This paragraph shall identify a site or 
set of sites and shall be divided into the following 
subparagraphs to discuss those sites. Multiple sites 


may be discussed together when the information for 
those sites is generally the same. 


le aaa k Schedule. This paragraph shall present a schedule of 
activities 
to be accomplished by the user during installation. It 
shall depict the required tasks in chronological order, 
including beginning and ending dates for each task, 
with supporting narrative as necessary. 


ee ae ey, Detailed procedures. This paragraph shall be divided 
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subparagraphs to present the step-by-step procedures 
required to accomplish the installation, including 
conversion. Reference may be made to other documents, 
such as user manuals. The procedures shall. include 
the following, as applicable: 


Initiation procedures 

Input formats 

Output formats 

Utilization of outputs 

Procedures for recovery, error correction, and 
continuity of 

operations in emergencies 
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Data _ update procedures. This paragraph shall be 
divided into 


subparagraphs to present the user’s data update 
procedures to be followed during the installation 
period. When update procedures are the same as normal 
processing, reference may be made to other documents, 
such as user manuals, and to Section 4 of this 
document, aS appropriate. The procedures shall 
include the following, as applicable: 


: Initiation procedures 

Input formats 

Output formats 

Utilization of outputs 

Procedures for recovery, error correction, and 
eoutinuity of 

operations in emergencies 
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Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of terms and definitions needed to 
understand this document. If section 5 has 


been expanded into section(s) 6,...m, this section 
shall be numbered as the next section following section 
ia. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall. be referenced in the 
main body of the document where the data would normally 
have been provided. 
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